DEV Community: SpriteShip Team

From Prompt to Playable: Building a Phaser Survival Game with Codex and SpriteShip

SpriteShip Team — Sat, 22 Aug 2026 18:22:01 +0000

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:

this.load.atlas(
  PLAYER_ATLAS,
  "assets/spriteship/player/spritesheet_walk_256.png",
  "assets/spriteship/player/atlas_walk_256.json"
);

Animation registration can use the frame list supplied by the atlas instead of assuming a fragile numeric range:

const definition = atlasData.animations.walk;

scene.anims.create({
  key: "player-walk",
  frames: definition.frames.map((frame) => ({
    key: PLAYER_ATLAS,
    frame,
  })),
  frameRate: 60,
  repeat: -1,
});

The player switches to the walk cycle while moving and to SpriteShip’s idle_2 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 collision tuning into something a non-programmer could evaluate visually.

The dashboard-and-agent loop worked well

One of my favorite parts of the workflow was mixing dashboard edits with Codex-driven integration.

At one point, the humanoid attack animation was adjusted in the SpriteShip dashboard. Instead of manually exporting everything and explaining what changed, the updated asset could be fetched again and repackaged for the game. The same happened with collectible cleanup.

The division of labor felt sensible:

The human selected and visually edited assets.
SpriteShip managed the project and generated structured outputs.
Codex synchronized files, generated runtime variants, updated Phaser code, and ran tests.

It was a much smoother loop than downloading miscellaneous images, renaming them by hand, and guessing how they should be sliced.

Resolution is not only width and height

The most useful lesson from the project was that two 256×256 frames are not necessarily the same visual size.

The player’s walk and idle animations both had 256×256 runtime frames, but the character initially occupied a much smaller part of the idle frame. When the game switched states, the player appeared to shrink.

We measured the visible pixel bounds and found roughly:

Walk footprint: 158×179 pixels
Initial idle footprint: 109×111 pixels

The fix was to rebuild the idle runtime sheet from SpriteShip’s original 512×512 frames, normalize the character around the same ground anchor, and then export back to 256×256 frames. That produced a much closer 176×178 pixel footprint without throwing away source detail.

This was not a failure of the integration. It was a reminder that a real asset pipeline must consider transparent padding, subject scale, ground contact, and intended display size—not just file dimensions.

The same principle guided the other assets:

Weapons: 32×32 source and runtime display target
Collectibles: 64×64 source and runtime display target
Animated characters: larger source frames with consistent visual occupancy

Once those rules were explicit, the game looked much sharper and more cohesive.

What SpriteShip made easy

Several things that normally consume a lot of setup time were refreshingly straightforward:

Consistent asset families

The player, enemies, weapons, and collectibles belong to the same visual world. Achieving that consistency across dozens of independent assets is usually difficult.

Animation metadata

Named animations, FPS, loop state, frame lists, and preview GIFs made integration predictable.

Multiple runtime sizes

Having access to larger sources and smaller runtime variants let us make sensible choices for desktop and mobile instead of scaling one image everywhere.

MCP/API access

The API key stayed in the local environment, and Codex could work with SpriteShip as part of the development process. There was no need to build an asset-management service inside the game.

Human-in-the-loop editing

The dashboard remained valuable even in an agent-driven workflow. This was not “type one prompt and accept everything.” It was a collaborative process where visual judgment and automation complemented each other.

The results were not magically perfect—and that is fine

A believable account of AI-assisted creation should include the iterations.

The first character direction was not exactly right. One collectible sheet included labels that were useful for review but not for runtime use. Animation families needed scale normalization. Playback speed needed tuning after a walk cycle changed frame count. Collision bodies needed to be visualized before they could be trusted.

What impressed me was how inexpensive those corrections were in the overall workflow. We did not have to discard the pipeline every time something changed. We could revise an asset, fetch the new version, and update the game.

That is a more meaningful kind of speed than getting a perfect image from one prompt.

Building a sample repository

The finished game became the first entry in a dedicated SpriteShip sample-games repository:

spriteship-game-samples/
├── README.md
├── package.json
└── games/
    └── last-light/
        ├── README.md
        ├── PRD.md
        ├── public/
        ├── tests/
        └── package.json

Each future game can live in its own workspace with independent assets, tests, and build scripts. The root repository acts as a catalog rather than forcing every sample into one application.

This structure also makes the examples useful to developers. They can inspect the actual atlases, animation registration, collision conversion, and resolution choices instead of only seeing a promotional demo.

What I would do next

The obvious next step is to add samples in other genres and engines:

A platformer with state transitions and hit reactions
A tactics prototype using character directions and tilemaps
A Godot sample using the same SpriteShip project concepts
A small multiplayer arena with cosmetic variants

I would also like to see engine-specific SpriteShip exports become even more opinionated: a Phaser loader module, recommended display sizes, per-frame opaque bounds, and a compact synchronization manifest would make an already smooth workflow nearly automatic.

Final thoughts

Codex made it possible to keep implementation, asset processing, testing, and iteration in one development thread. Phaser made the runtime lightweight and immediate. SpriteShip supplied the piece that usually holds prototypes back: enough coherent, animated art to make the game feel intentional.

The standout feature was not simply that SpriteShip generated good images. It was that the service fit into a real engineering loop. Assets had identities, versions, animations, collision data, previews, and dashboard edits. The MCP/API interface made those capabilities accessible without turning the project into an asset-management exercise.

Last Light still involved judgment and iteration, as every game does. But the distance between “I want a top-down survival game” and “I can play one with a coherent animated cast” was much shorter than I expected.

That is the kind of AI-assisted workflow I find genuinely useful: not replacing the creative process, but removing enough friction that the process can keep moving.

Play the game: https://spriteship.github.io/sample_games/last-light/

Project repository: https://github.com/spriteship/sample_games

Tools: SpriteShip, Codex, Phaser 3

How to give a coding agent a complete 2D game-art pipeline over MCP

SpriteShip Team — Thu, 20 Aug 2026 12:42:02 +0000

Most coding agents can write the player controller, register an animation, and
load a texture atlas. They usually stop at the point where the art has to exist.

That boundary is awkward for an autonomous workflow. An image generator can
produce a PNG, but the agent still has to guess how to split frames, name
animations, build an atlas, define collision, and package everything for the
engine.

SpriteShip's hosted Model Context Protocol server is meant to close that gap. It
currently exposes 41 tools for creating, reading, revising, animating, and
exporting a game's 2D art layer.

The cover image for this article was AI-generated with SpriteShip.

What the agent can actually make

The tool surface covers more than characters:

animated characters and directional turns;
static props and animated objects;
tilesets, terrain sheets, backgrounds, and seamless textures;
level maps assembled from those assets;
engine-native exports for Phaser, Godot, Unity, GameMaker, and Tiled.

The important part is the sequence. An agent can create a project, generate an
asset inside it, poll the asynchronous job, inspect the result, and export files
without requiring somebody to first prepare the entity in the web dashboard.

Connect the MCP server

Create a scoped API key in SpriteShip under Account → API keys, then expose it
to the process running your agent:

export SPRITESHIP_API_KEY="ss_live_..."

The MCP endpoint is:

https://spriteship.com/mcp

An MCP client configuration has three essential fields:

{
  "mcpServers": {
    "spriteship": {
      "url": "https://spriteship.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SPRITESHIP_API_KEY}"
      }
    }
  }
}

The exact config-file location differs between Claude Code, Cursor, Windsurf,
Cline, and Codex, but the endpoint and authorization header are the same.

Start with a project

Characters and assets live inside a project. The project also owns the permanent
game perspective that guides later generations: platformer, angled top-down,
straight overhead, isometric, or point-and-click.

create_project is synchronous and free. A typical instruction to the agent is:

Create a platformer project called Clockwork Harbor. Use a hand-drawn style and
describe it as a foggy port city powered by unreliable brass machinery.

Before creating anything, the agent should call list_projects and reuse a
matching project rather than creating a near-duplicate.

Generate four character options for one image call

create_character makes the initial character image. Setting both gridRows
and gridCols to 2 asks for a four-variation sheet. It is still one image call,
so the four resulting character designs have the same generation cost as one.

That makes the sensible first workflow:

Request a 2×2 set of character variations.
Poll the returned job with get_job.
Show the four characterPreviews to the user.
Animate only the selected design.

Generation is asynchronous. The create call returns a jobId; when the job is
finished, get_job returns the created character IDs and expiring preview URLs.

Preview the cost before spending

Paid SpriteShip MCP tools default to dryRun: true. A dry run returns the
estimated credit cost, current balance, daily spend cap, recent spend, and
remaining cap. It generates nothing.

The expected exchange looks like this:

user: make four plague-doctor character concepts for this project

agent: the generation is estimated at 150 credits. Your balance after the call
       would be 1,350 credits. Shall I run it?

user: yes

Only after that explicit approval should the agent repeat the call with
dryRun: false.

This is backed by server-side controls rather than prompt etiquette:

API keys have separate read, write, and spend scopes;
each key has a daily credit ceiling;
real writes are idempotent, so a retry cannot dispatch and charge twice;
writes against a busy entity are rejected instead of racing;
revoking a key cancels its unfinished jobs.

When a job reaches a terminal state, the agent should report the job's actual
net charge rather than repeating the estimate. Four variations still come from
one charged image call, and failed steps can change the final amount.

Add real motion

The still image and its animations are intentionally separate decisions.
generate_character_animation creates image-to-video motion such as a walk,
idle, attack, or dodge. Each generated animation is a separate paid video call,
so the agent should ask which motions are actually needed.

For directional characters, a generated direction can also produce a free
mirrored copy in the same job. A real second generation is still the right choice
for an asymmetric character, because mirroring moves a held item to the opposite
hand.

Recent animation work also makes the generated motion more usable downstream:

the starting pose is checked for visual inventory so empty hands remain empty and existing held items are preserved;
occupied animation names resolve non-destructively (jump, jump_2, jump_3);
jump animations can be split into takeoff, airborne, and landing phases;
character exports carry ten skeleton-derived attachment points for equipment and effects.

Export something the engine understands

Once the character is ready, get_export_command returns an authenticated URL
and a ready-to-run curl command for the chosen engine. The agent runs that
command in its own shell rather than passing a multi-megabyte zip through the
language model.

An export can contain:

sprite sheets and atlas metadata;
native engine resources;
animation names and frame timing;
collision shapes and ground footprints;
per-frame equipment attachment points;
a manifest, JSON Schema, README, and SpriteShip skill instructions.

That last group matters. The bundle explains its own structure, so the coding
agent can register the animation in the game instead of inventing a file layout.

A useful end-to-end prompt

After connecting the server, try an instruction shaped like this:

Create a platformer project for a clockwork harbor game. Preview the cost of
four character designs for a lantern-carrying mechanic. Wait for my approval
before spending anything. When they finish, show me the options and let me pick
one. Then quote an idle and walk animation, generate only after I approve, and
export the result for Phaser.

That single request exercises the important boundaries: project context, cost
preview, explicit approval, asynchronous jobs, visual selection, separate
animation spend, and engine-native export.

Where to go next

Agent overview and setup guides: https://spriteship.com/agents
MCP endpoint: https://spriteship.com/mcp
API and key management: https://spriteship.com/account/api-keys

SpriteShip includes 1,500 starting credits and does not require a card to try the
first workflow. Reading existing assets and re-exporting them are free; credits
are used for new AI generations.