There is a big difference between a game prototype that technically works and one that feels like a game.
Movement, spawning, upgrades, and collision can be built with colored rectangles.
That is often the right way to start.
But the moment you want an animated player, a family of enemies, weapon variety, collectibles, and a consistent visual identity, the art pipeline can become the project.
For a recent experiment, I wanted to see how far I could get by combining three tools: Phaser 3 for the game runtime Codex for implementation and iteration SpriteShip for game-ready visual assets through its MCP/API workflow The result was Last Light, a top-down survival game that runs in desktop and mobile browsers.
It has an animated player, multiple enemy families, a large humanoid with separate walk and attack animations, sixteen weapons, sixteen collectibles, upgrades, an objective, and a boss encounter.
Play Last Light: https://spriteship.github.io/sample_games/last-light/ Browse the source repository: https://github.com/spriteship/sample_games More importantly, it became playable through a surprisingly natural loop: describe an asset, generate it in SpriteShip, inspect or revise it, and let Codex wire the exported data into Phaser.
Starting with gameplay, not presentation The first version was intentionally plain.
It established the systems that mattered: Top-down movement Automatic targeting and firing Enemy spawning and difficulty progression Experience drops and upgrades Desktop and touch input A camera following the player across a large map That gave us something useful to evaluate.
Once the loop was playable, every art decision could be judged in motion rather than in isolation.
This order mattered.
SpriteShip did not have to invent the game design; it could supply assets for systems that already existed.
Creating a coherent project in SpriteShip Instead of making unrelated images one at a time, we created a top-down overhead project in SpriteShip.
That project context helped keep the blackout-survival direction consistent across characters, enemies, weapons, and collectibles.
The player went through a normal creative selection process.
We generated options, selected a character, refined the camera angle and facing direction, and then added animation states.
The same process produced: A player walk cycle A separate idle animation Four creature enemies A larger weaponless humanoid enemy Humanoid walk and attack animations A 4×4 weapon set A 4×4 collectible set The useful part was not just getting PNG files.
SpriteShip returned structured animation data: atlas frames, FPS, looping behavior, source sizes, previews, and collision-body definitions.
That is where the MCP integration started to feel less like image generation and more like a game-development tool.
Wiring SpriteShip animations into Phaser Phaser’s atlas support maps naturally to SpriteShip’s exports.
The loader only needs the sheet and its JSON metadata: Animation registration can use the frame list supplied by the atlas instead of assuming a fragile numeric range: The player switches to the walk cycle while moving and to SpriteShip’s animation while stationary.
Because the animation data is named and versionable, updating a dashboard edit is much safer than manually rebuilding frame sequences.
Collision data was more useful than I expected SpriteShip supplied normalized rectangular collision bodies for individual animation states.
We converted those values into rotated world-space rectangles inside Phaser.
For the humanoid enemy, the body changes when the attack animation begins.
The attack pose is wider and lower than the walk pose, so using a single circular approximation would have produced misleading hits.
The final game uses the same authored rectangle for: Projectile collision Enemy melee contact Debug visualization That last point was important.
Drawing the rectangle on screen made it immediately obvious whether gameplay matched the artwork.
It also turned co