DEV Community: SpriteShip Team

Editing a Top-Down 2D Map: Paths, Regions, and Elevation

SpriteShip Team — Tue, 20 Oct 2026 12:30:02 +0000

Top-down levels are easy to fill and surprisingly hard to read. A large field of attractive ground can still leave players unsure where to go, which objects block them, or whether a raised area is reachable.

The most useful map editing habit is to build a clear route before filling the screen with detail.

Sketch the regions and connections

Start with the major places: a village square, a wooded approach, a riverbank, or a dungeon room. Decide how the player moves between them. Paint the broad terrain regions first, then add a path that connects the important destinations.

In SpriteShip, a Terrain layer can use multiple Materials. That lets you paint grass, dirt, stone, or another ground look within one editable map. Change brush size as you move from broad areas to narrow turns. Use visual contrast to show where a path continues, especially near intersections.

The top-down map editor guide covers terrain painting, layers, map settings, and preview.

Use height as a navigation cue

Raised ground can make a map more interesting, but it creates a new question: how does the player get there? Add a ramp where movement should be possible, then check the route from both sides. Shading can make a height break visible; it does not replace a deliberate movement rule.

If the map is mostly flat, you can still get useful structure from Material changes. A stone floor can announce a town boundary, while a dirt track can guide the eye through grass. Repeatable 2D terrain Materials give those regions a consistent look across a larger map.

Add objects in readable layers

Place buildings, trees, props, and characters after the basic route works. Use Object layers to organize them and inspect the draw order. Decide which objects are solid, which are decorative, and which carry gameplay data such as a trigger or spawn point.

Look at the map at the size players will actually see. A route that is obvious when zoomed out may disappear behind a building or a dense row of trees in game preview.

Walk the map before export

Set a player spawn, preview movement, and try to reach each important region. Fix blocked or confusing routes. Then test once more after adding the final scenery.

When the layout holds together, export the top-down map for your game engine. You can return to the same editable map to revise a path or swap a Material later.

The aim is not a screen full of assets. It is a world the player can understand and move through.

Editing a 2D Platformer Map: From Ground Shape to Playable Route

SpriteShip Team — Wed, 14 Oct 2026 12:30:02 +0000

In a platformer, the map is a sequence of movement decisions. A ledge asks the player to jump. A slope changes the pace. A low ceiling changes which actions feel safe. Editing the map means shaping that route, then making sure the art and collision communicate the same thing.

Here is a practical way to build one in SpriteShip.

Block out the route first

Start with the player's path through the level. Place the main ground, major gaps, and changes in height before decorating. A Terrain layer lets you paint broad masses quickly, then refine a landing zone or tunnel with a smaller brush. For side-view ground, choose a Material that makes the top surface easy to read.

Keep early tests simple. If a jump is hard to judge with plain terrain, adding more scenery will not fix it. Check the gap length, landing width, and the silhouette of the next platform.

The 2D level editor is where you paint terrain and keep the map editable as these shapes change.

Separate gameplay from dressing

Use Object layers for things like bridges, doors, hazards, and foreground details. Place them after the route works. Layer order decides what appears in front, while solid and collider settings help distinguish a physical obstacle from a visual prop or trigger.

Put the player spawn where a real playtest should begin. If the level has a one-way platform or an overhang, approach it from both directions in preview. What looks clear in an editor can feel ambiguous once a character is moving at speed.

Make slopes deliberate

A slope should support the movement you want: a climb, a descent, or a smooth transition into a jump. Paint the terrain shape, then check its contact behavior and the character's route across it. Visual styling can make the incline easier to see, but it does not decide how your game's controller should handle acceleration or jumping.

This is where reusable platformer terrain Materials help: you can change the ground's look while continuing to edit the path itself.

Preview, revise, export

Test a short loop: spawn, move, jump, land, turn around, and exit. Fix confusing geometry before adding detail. Then place the assets that establish setting and mood, and test again with the final layers visible.

When the route feels right, export your platformer map for the target engine. Keep the editable map as your source so another pass on jump spacing or terrain art does not mean rebuilding the level.

A good platformer map is readable at running speed. That is the standard to use throughout the edit.

How Terrain Materials Work in a Top-Down 2D Game

SpriteShip Team — Thu, 08 Oct 2026 12:30:03 +0000

A top-down map has a different readability problem from a platformer. The player sees the ground as a field: paths, clearings, shorelines, floors, and raised areas all compete for attention. The material underfoot should help the player understand the space without drowning out characters and objects.

SpriteShip Materials are reusable ground looks for that job. You generate visual options that match the project, choose the ones you like, and paint them where they belong in an editable map.

Think in regions, not isolated tiles

Suppose you are building a forest village. Grass might cover most of the map, dirt could mark the main route, and stone could identify a market square. Those choices do more than decorate: they establish a visual hierarchy. A player can follow the path at a glance, notice a change of area, and distinguish an accessible square from background detail.

Top-down Material generation gives you several repeatable fill options to review. Inspect a repeated preview before covering a large area, particularly if the game uses a camera that moves across the map. The goal is a surface that feels coherent beyond one screen.

The guide to generating 2D ground Materials explains how to create and review those assets.

Paint, then add height where it matters

Choose a Material on a Terrain layer and paint broad areas first. Add a second Material for routes or distinct zones, then refine the boundaries with a smaller brush. For a top-down map, this is often faster to reason about than selecting an individual corner tile for every turn in the path.

If the world has raised ground, use elevation and ramps to express the route through it. Visual shading can help a height change read clearly, but the map's movement rules still need to be tested. Decide whether the player can reach the higher area, where the ramp begins, and what should block movement.

You can also place trees, buildings, and other props on Object layers above the terrain. Keep the most important paths visible: a beautiful ground treatment is less useful if a player cannot see where to move.

Review the whole scene

Zoom out and ask three questions: Can I see the route? Can I tell which regions differ? Do characters remain legible against the ground? Then preview the map at the camera size your game will use.

SpriteShip's top-down level editor guide covers painting terrain, placing assets, and testing the map. You can export the finished 2D map while keeping the source editable for later changes.

A Material makes the world visually consistent. Good top-down level design still comes from the paths, boundaries, and decisions you paint with it.

We Built a Browser Strategy Game with Codex, SpriteShip, and Godot

SpriteShip Team — Tue, 06 Oct 2026 09:12:11 +0000

We wanted a 2D strategy game where you could gather wood, stone, gold, and food, build a settlement, recruit soldiers, upgrade structures, and eventually lead an army into battle.

The inspiration was the settlement-building loop of classic RTS games, with direct control of a hero. The world and characters would be original. The game had to run in a browser, and all its illustrated assets had to come from SpriteShip.

The result is Emberhold: The Last Hearth, a Godot game with a story campaign, a peaceful sandbox, and a public web build.

Watch the gameplay video

Codex handled the coding and tool-driven implementation. SpriteShip supplied the illustrated assets and their export data. Godot brought the systems together.

Here's what that process actually looked like—including the parts that still need work.

Start with a game vision, not an asset list

Our initial request described a genre and a visual ambition. It did not specify every building, character, quest, or balance value.

We asked Codex to turn that into a product requirements document before implementation. A cleaned-up version of the brief would look like this:

Build an original 2D settlement strategy game in Godot for the web.

The player gathers resources, constructs and upgrades buildings,
recruits soldiers, explores the map, and fights enemies.

Use SpriteShip for every illustrated game asset.
Define the story and campaign objectives before implementation.
Keep SpriteShip production within a 30,000-credit ceiling.
Validate the game in the engine and in a real browser.

That planning step gave the art and mechanics a shared direction.

Captain Elara arrives in a ruined valley with survivors and a coal from the last living hearth. Rebuilding the settlement lets her recruit an army, rekindle three beacons, and confront Veyr, the Ash Regent.

The campaign has five chapters. Its progression moves from gathering and construction to recruitment, exploration, beacon liberation, and the final battle.

The PRD is in the repository, alongside the implementation.

Give Codex tools and an explicit workflow

For this build, Codex could inspect and edit the repository, run commands, call SpriteShip's API/MCP tools, download exports, and examine the resulting game.

We also supplied SpriteShip's current agent instructions. Those instructions covered generation, export contracts, synchronization, collision metadata, quality review, and spending controls.

There are two useful layers here: tools expose operations, while a skill explains the workflow around them. That's also the distinction described in the official OpenAI documentation on skills.

In our production scripts, the loop became:

Define the asset and its role
  → obtain a generation quote
  → check it against the authorized budget
  → submit and wait for the job
  → download the native export
  → integrate, inspect, and test

The scripts retained request state and used idempotency keys for paid operations. They also needed file locking when multiple production operations updated shared state.

The point was to make the agent's work inspectable: which assets were requested, which jobs finished, what was imported, and what actually cost credits.

Build a coherent art pack

We chose an angled top-down, painted fantasy style: mossy greens, ivory stone, copper roofs, warm settlement lighting, and ember-red enemy accents.

The SpriteShip project supplied the illustrated menu scene, terrain, nature props, resource deposits, structures, fortified building variants, landmarks, characters, icons, and ornamental UI.

The character lineup includes Elara, settlers, guards, rangers, knights, raiders, and armored brutes. The final boss uses the brute artwork at a different scale.

Godot code supplies lighting, particles, text, interface layout, and gameplay. Music and sound effects are synthesized at runtime rather than imported as generated audio files. Fonts arrived through SpriteShip with their license notices.

We later changed the account's watermark setting and downloaded every selected asset again, including the whole-character, map, and UI bundles. We did not paint over watermarks locally.

That refresh also reinforced a useful production rule: store local asset bytes and stable identifiers, not expiring download URLs.

Native exports make integration concrete

SpriteShip's Godot character bundles include native .tres animation resources, spritesheets, manifests, and integration instructions. Its Codex integration guide describes these self-describing exports.

Codex read the delivered animation names, frame order, and playback data rather than inventing a spritesheet layout.

Our project keeps an asset lock file and a local runtime manifest. The lock records imported entities and versions; the runtime manifest routes game archetypes to their local art and animation resources.

The final synchronization check covered 18 entries, all matching the downloaded versions.

The surprisingly tricky part: feet

A character can look great in an individual frame and still look wrong when it switches animations.

Different clips had different amounts of transparent padding. Without calibration, standing and walking could appear to change the character's size or ground contact.

We used a fixed neutral-first-frame reference for each clip to calibrate visible height and the foot anchor. This is a per-clip render adjustment, not a crop that changes on every frame.

Movement footprints were authored back into SpriteShip separately from full-body hurtbox metadata, then downloaded in fresh native exports. The full, untrimmed logical frame coordinates were retained.

For browser delivery, we applied a paired 50% scale to the character sheets and every corresponding atlas rectangle. Scaling only the image would leave the atlas pointing at the wrong pixels. Full-resolution native sources were retained locally.

These integration details were a substantial part of the work. Generating the image was only one step.

Build the game systems in Godot

The shipped game uses Godot 4.7.2 and GDScript. Node.js handles production and build tooling; it is not the gameplay engine.

The main systems include:

Hero movement, contextual gathering, melee attacks, healing, and dashing.
Settlers that travel to deposits and gather resources autonomously.
Eleven structure types, construction progress, upgrades, repairs, and population limits.
Guard, ranger, and knight recruitment, with follow, defend, rally, and assault orders.
Research, ranged projectiles, defensive towers, enemy camps, and escalating raids.
Three beacons, a protected citadel, a final boss, campaign progression, and save/load.

The authored valley is 4096 × 3584 pixels. Godot handles obstacle-aware navigation with AStarGrid2D, exploration, fog, interactions, and the gameplay meaning of the map data.

The source is split into recognizable responsibilities: game.gd owns simulation and saves, world.gd handles rendering and animation selection, hud.gd manages the interface, and data.gd holds unit, building, and story definitions.

You can inspect that division in the Godot project source.

Test actions, not just screenshots

We used two different kinds of validation.

First, native Godot acceptance scenarios exercised gathering, settler travel, navigation routes, placement, upgrades, completed recruitment queues, research, repairs, projectiles, saves, beacon activation, and final victory.

Those tests use prepared resources and cleared beacon guards where appropriate. They are systems tests—not evidence of a complete human campaign playthrough or a measured campaign duration.

Second, an isolated Chromium browser used real mouse and keyboard input. It moved Elara, placed structures, waited for settlers to collect resources, recruited troops, upgraded a barracks, saved, reloaded, and continued the settlement.

The browser also led an army to the first beacon, defeated five enemies, used healing, and rekindled it. We repeated these checks against the public GitHub Pages build.

The public-site run passed with all seven character archetypes registered and zero browser console or page errors. Screenshots covered multiple desktop viewport sizes.

The browser tests inspect a read-only state snapshot; they do not use a debug API to grant resources or complete objectives.

Ship the web build through GitHub Pages

The repository already hosted another game, Last Light. We extended its Pages build so Emberhold could live alongside it:

https://spriteship.github.io/sample_games/emberhold/

We used Godot's Compatibility renderer and a single-threaded Web export. Single-threaded exports avoid the cross-origin isolation headers required by threaded builds, which makes this a practical fit for static hosting. See Godot's web export documentation.

The Linux CI build installs the pinned Godot version and matching Web templates, verifies their SHA-256 checksums, runs the tests, exports the game, and packages both games into the Pages artifact.

Generated web builds stay out of Git. The repository contains the source and illustrated assets; CI rebuilds the deployable files. Playing or deploying the game requires no SpriteShip API key.

To rebuild locally, install Godot 4.7.2 with matching Web export templates and Node.js 22+, then run:

git clone https://github.com/spriteship/sample_games.git
cd sample_games
npm ci
npm run build:emberhold
npm run dev:emberhold

The local game runs at http://localhost:4174. Saves on the public site are separate from localhost saves.

What it cost—and what still needs work

Our audited SpriteShip production spend was 14,360 credits net, against the authorized 30,000-credit ceiling. That includes generation failures and provider refunds recorded in the ledger. It is an art-production figure, not the total cost of development or a dollar-price estimate.

The original brief asked for an AAA-style 2D look. That was an ambition, not a certification of the result.

This is a playable single-player campaign and sandbox on one map. It still needs animation polish, broader hardware testing, and longer balance playtests. In particular:

Gathering reuses strike/chopping clips rather than having distinct animations for each resource.
Hero death currently restores health and returns Elara home immediately, which needs a clearer death-and-recovery sequence.
Three gameplay building levels share two delivered artwork tiers; level III reuses fortified art with a crown marker.
Some optional attack directions failed at the provider, so delivered animations serve as fallbacks. Quality-review flags remain documented.

It does not include multiplayer, voice acting, mobile touch controls, or a multi-map campaign. The QA record explains the validation and limitations.

The takeaway

Codex let us work through planning, implementation, asset orchestration, debugging, testing, and deployment in one ongoing workflow. SpriteShip gave that workflow a source of illustrated assets with native export data the agent could inspect and integrate.

The most useful combination was a clear game brief, a coherent art direction, explicit asset contracts, bounded spending, and tests that exercised actual player actions.

There is still polish to do. But the result is a public game you can play, with source you can inspect and a production process you can follow.

Try Emberhold, browse the repository, or explore SpriteShip and the game's art project.

If you play it, I'd love feedback on the settlement pacing, army controls, and what feels most important to improve next.

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.