DEV Community: SpriteShip Team

How Terrain Materials Work in a 2D Platformer

SpriteShip Team — Fri, 02 Oct 2026 12:30:03 +0000

A platformer level is read from the side. Players need to see where they can land, which surfaces they can pass through, and where a slope begins. A good ground texture helps, but a repeating image alone cannot answer those questions.

That is why a Material in SpriteShip is a reusable terrain choice, not a finished level. You create the visual look of ground, then decide where that ground belongs on the map.

Start with the ground's visual identity

Imagine a hillside level with grassy earth above a stone tunnel. You might want a soft green top edge, a darker soil body, and a separate stone look below. Generate Materials that fit the project's art direction, then inspect how the artwork repeats before you build a long stretch of terrain.

In a platformer, a Material pairs the appearance of the ground's interior with a visible surface treatment. That lets a ledge read as a ledge while the body of the terrain still feels continuous. You can review the result and choose the look you want to use in the level.

If you are starting from scratch, the SpriteShip guide to creating 2D terrain materials walks through the asset workflow.

Paint the shape players will navigate

In the map editor, add a Terrain layer, choose a Material, and paint the mass of the ground. A wider brush blocks out the level quickly; a smaller brush helps refine a jump landing, tunnel entrance, or narrow platform. You can use more than one Material on the same layer, so the visual theme can change without rebuilding the map from separate image rectangles.

Slopes are especially useful in a side-view game. A gentle rise can lead the player into a new area without turning every elevation change into a staircase. The important design decision is still yours: where does the player climb, jump, stop, or fall?

Keep appearance and gameplay readable

The same terrain can look different under different rendering styles. You can tune scale, edge treatment, and blending to suit pixel art or a softer painted world. Then review contact and collision settings separately. A decorative surface does not become good gameplay merely because it looks solid.

Playtest the route: approach a slope, land on an edge, pass under an overhang, and check one-way platforms where you use them. The map should communicate those actions before the player has to guess.

The 2D platformer map editor workflow covers Terrain layers, objects, preview, and export. When the level is ready, export the map for your game engine and keep the editable source for later changes.

The useful mental model is simple: the Material supplies a consistent visual language; you author the playable shape.

From AI-Generated Game Assets to a Playable 2D Game Level

SpriteShip Team — Fri, 25 Sep 2026 15:30:07 +0000

AI-generated game art is most useful when it becomes part of a real production workflow.

A single image can be inspiring, but a game needs more: consistent visual direction, reusable assets, terrain, background layers, placement, revision, and an export path into the engine. The interesting question is not “Can AI make an image?” It is “Can that image help a creator build a playable level?”

Here is the workflow we are building around in SpriteShip.

Start with a visual language

Before generating individual objects, establish the game’s perspective, palette, lighting, and overall style. A platformer, top-down RPG, and isometric adventure may all use the same subject matter, but they need different composition and camera treatment.

A clear visual direction makes later assets feel like part of the same game instead of a collection of unrelated images.

Give every asset a job

Game assets are easier to work with when their role is explicit.

Backgrounds establish the scene, distant depth, or foreground framing.
Environment Kits provide placeable world props and details.
Object Collections produce matching groups of items, icons, cards, or variants.
Object States represent meaningful changes such as growth, damage, construction, or activation.
Materials provide reusable terrain that can be painted in the map editor.

Thinking in roles helps turn an art request into a level-building system.

Build the map, not just an image board

Once assets exist, the map editor becomes the place where composition turns into a playable space.

Place props, paint terrain, define layers, refine shapes, and preview the level as it comes together. This is where the game starts to develop its own visual rhythm: open areas, routes, landmarks, foreground framing, and places for interaction.

The important part is that these choices remain editable. A useful workflow should make it easy to move an object, change terrain, replace a background, or revise an asset without starting again.

Keep AI in the right role

AI can accelerate exploration and help create a coherent starting set of art. It does not replace art direction, level design, accessibility review, gameplay design, or the judgment needed to decide whether an asset belongs in the game.

Treat generated art as a creative input. Review it, edit it, place it intentionally, and keep iterating.

Export when the level is ready for development

When the map is ready to leave the editor, export it into the supported game workflow. The handoff should preserve useful facts such as the artwork, placed objects, map layers, terrain, and other authored data.

Developers can then focus on the game-specific work: player controls, AI, interactions, combat, missions, and progression.

A practical loop for indie teams

Define the visual direction.
Create assets with clear roles.
Assemble and refine the level.
Test the layout and gameplay assumptions.
Export, implement, and iterate.

The payoff is not a fully automated game. It is a tighter loop between an idea, the art needed to express it, and a level that developers can actually build on.

Build a consistent 2D game-art pipeline at spriteship.com.

Exporting One 2D Map to Phaser, Godot, Unity, GameMaker, and Tiled

SpriteShip Team — Fri, 18 Sep 2026 15:30:00 +0000

Choosing a game engine should not mean rebuilding the same map from scratch.

That sounds obvious, but 2D map workflows often become tied to one editor, one file format, and one runtime. The artwork might travel easily; the map data usually does not. Layers, placement, collision, terrain, metadata, and draw order are often rebuilt by hand whenever a prototype moves to a different engine.

We built SpriteShip’s map export workflow around a different idea: keep one editable source map, then package it for the engine or toolchain you need.

A map is more than a screenshot

Exporting a flattened image is useful for a mockup, but it is not enough for an interactive game. A playable map needs information about layers, placed assets, transforms, collision, terrain, navigation, and custom gameplay data.

If that information disappears during export, the receiving engine gets pixels—but not a usable level.

Keep the source map editable

The source map should preserve the facts a creator authored: the map’s layers, terrain, object placement, visual order, transforms, and gameplay-oriented metadata.

That means the same project can be revised without treating an exported file as the new source of truth. Move a prop, reshape terrain, adjust a layer, then export again from the map you actually edit.

Export for the target, not for a lowest common denominator

Different engines expect different project structures. A useful export should respect the target while preserving the meaning of the map.

SpriteShip currently supports map exports for:

Phaser
Godot
Unity
GameMaker
Tiled

Each export is built from the same editable map rather than from a separate manual recreation. Unreal Paper2D export is also available in beta for teams exploring that workflow.

Why cross-engine export matters for small teams

Indie projects change. A prototype may start in a browser game framework, move into a desktop engine, or need to share level data with a teammate using a different tool. Keeping the map editable and portable makes those changes less expensive.

It also helps when you are evaluating engines. You can test the same level in more than one runtime without throwing away the work that got you there.

Export is a handoff, not automatic gameplay

A map export can preserve artwork, placement, layer order, collision information, terrain, and metadata. It cannot decide how a specific game should handle combat, AI, quest logic, save systems, or player movement.

Those choices still belong to the game team. The goal is to make the asset and level handoff dependable, so developers can spend their time on the parts that make their game distinct.

The workflow we want

Build the level once. Keep editing the same source map. Export it for the engine you need today—and re-export when the map changes tomorrow.

That is a better foundation for experimentation, collaboration, and shipping a 2D game.

See the full SpriteShip workflow at spriteship.com.

Building a 2D Terrain Editor: Auto-Tiling, Slopes, and Collision

SpriteShip Team — Fri, 11 Sep 2026 15:30:00 +0000

A 2D terrain editor should let creators think in terrain—not in a catalogue of corners, edge tiles, and one-off fixes.

When a map is built tile by tile, a small visual change can become a maintenance problem. Paint a new patch of ground and suddenly every transition, slope, collision boundary, and layer relationship needs attention. That friction is exactly what we set out to remove.

The terrain problem with tile-by-tile editing

Traditional tilemaps are powerful, but they ask creators to manage a lot of presentation detail themselves. A grass tile next to stone may need a different edge than grass next to sand. Platformer terrain needs slopes and solid surfaces; top-down terrain needs readable boundaries; isometric terrain needs consistent depth.

Those concerns are real, but they should not force a creator to hand-place every visual variation.

Paint terrain intent, not individual corners

In SpriteShip, a Material is a reusable visual recipe for terrain. Instead of selecting a specific corner or edge tile, you choose the material and paint the shape of the ground you want.

The editor retains the intent: where the terrain is, which material it uses, and the gameplay properties you chose. From there, it can render connected terrain appropriate to the map’s perspective.

That makes the result easier to revise. Want to widen a path, reshape a cliff, or replace grass with snow? Edit the terrain itself rather than rebuilding a patchwork of tiles.

Auto-tiling is only useful when it stays editable

Connected terrain should look intentional, but it also needs to survive iteration. The important part is not merely choosing neighboring tile art automatically. It is preserving an editable map representation so that visual details can be recalculated after the creator changes the shape.

This is especially valuable when the same project needs different terrain treatment across side-view, top-down, and isometric scenes.

Slopes, collision, and visual terrain belong in the same workflow

A playable map needs more than a good-looking ground layer. Platform surfaces, slopes, collision boundaries, and draw order all affect the game experience.

The editor keeps those decisions close to the terrain workflow: paint a region, refine its shape, preview the result, and verify collision before export. That gives creators a faster feedback loop without pretending that artwork alone can define gameplay.

A practical terrain workflow

Choose or create a Material that fits the project’s visual language.
Paint the terrain shape directly on the map.
Refine slopes, shapes, and layer order where the level needs them.
Preview the visual result and collision behavior.
Export the map for the engine you are using.

The goal is simple: keep terrain creation expressive enough for artists and structured enough for game development.

What this approach does not promise

It does not turn a rough idea into a finished level automatically. It does not guarantee that generated artwork is seamless in every situation, and it does not invent game logic, enemy behavior, or level design.

What it does provide is a more useful starting point: editable terrain that can be painted quickly, refined deliberately, and carried forward into a real game project.

That is the kind of map editor we want to use ourselves—one that removes repetitive work while leaving the creative decisions in the creator’s hands.

Explore SpriteShip’s 2D game-art and map-building workflow at spriteship.com.

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.