What a sprite sheet actually is

A sprite sheet is two things travelling together:

• The sheet — a single PNG that packs each animation frame into its own cell. Loading one texture is faster and tidier than loading twenty loose files.
• The atlas (the metadata) — a small file, usually JSON, that records the rectangle for every frame (x, y, width, height) and often its display duration. Your engine reads the atlas to know where frame 3 of the walk cycle sits, without you eyeballing pixel coordinates.

The frames themselves are just the poses of your animation in order: a six-frame walk cycle is six drawings of the same character, each a step further into the stride. Get those frames right, keep them the same size, and packing them is the easy part.

What you'll need

Just a browser. Tsubu runs entirely in the browser — no install, no download. Sign in with Google and your library is there on any machine. It's free for early adopters while we're in early access, with AI usage sponsored by the platform and no credit cap — so you can follow this whole tutorial without spending anything.

Step 1 — Get your frames

There are two honest ways to start. Pick whichever fits how you work; you can mix them freely.

Draw them by hand (the blank-canvas start)

Open the editor and start a new sprite at a real pixel size — 16×16 for a small character or UI icon, 32×32 when you want more room for detail. Whatever you choose, every frame in the animation has to share that exact size, so the engine can slice the finished sheet on a fixed grid.

Draw your first pose with the pencil, lean on a small palette so the whole cycle stays consistent, and keep the background transparent. Then build the cycle frame by frame: duplicate the frame you just drew, nudge the arm, shift the legs, and repeat. Four frames read as a walk; six or eight read as a smooth one.

Or start from an AI first pass (optional)

Sometimes you just need a starting grain, fast. Describe what you want — "a small green forest adventurer facing right" — and Tsubu drafts a finished sprite with the discipline real pixel art needs: a readable silhouette, a limited palette, clean edges and a transparent background, aligned to the grid rather than a blurry, downscaled photo.

Here's the part that matters for a tutorial like this: the draft comes back as real, editable pixels on the grid, not a flattened picture. It's a first pass, not a finished asset. AI is opt-in, it drafts and you refine, and because you keep every pixel it's yours to edit and honest to disclose — worth being transparent about where your frames come from, especially in a scene that cares. Below is that generated sprite imported into the Tsubu editor as a single 32×32 frame: the pixel grid, the tool rail, a constrained palette, and the animation timeline previewing at 12 FPS, all ready for you to refine the pose and add the rest of the cycle.

Already sitting on a finished GIF or an old PNG sheet from another tool? You can import it instead: bring the file in, tell Tsubu the frame size, and it lands as an editable animation on the timeline — the same starting point as the two paths above.

Step 2 — Animate on the timeline

However your frames got here, they now live on a filmstrip timeline. Reorder them, duplicate the ones you want to hold longer, and scrub the loop. Set the playback speed to taste — 8 to 12 FPS is the classic range for a walk; idles sit slower, attacks run faster. Every frame stays plain, editable pixels the whole time, so fixing a stray pixel on frame 4 is one click away. When the loop reads right in preview, it'll read right in your game.

Step 3 — Pack it into a sheet + atlas

This is the payoff. Export the animation and Tsubu packs every frame into a single PNG and writes a JSON atlas alongside it, in the familiar Aseprite / TexturePacker shape — frame rectangles, durations and sheet metadata included. An entry looks like this:

{
  "frames": {
    "walk_0": {
      "frame": { "x": 0, "y": 0, "w": 32, "h": 32 },
      "duration": 100
    },
    "walk_1": {
      "frame": { "x": 32, "y": 0, "w": 32, "h": 32 },
      "duration": 100
    }
  },
  "meta": { "size": { "w": 192, "h": 32 }, "scale": "1" }
}

Because the coordinates live in the atlas, your engine reads exact rectangles instead of guessing a grid. Need a still frame instead? Export a clean PNG scaled 1× to 8× with transparency preserved. Need a quick share for a devlog? One-click animated GIF.

If you already have your frames prepared and only want the packing step — drop files in, preview, download the sheet and atlas — that job has its own home: our sprite sheet maker does exactly that, and this tutorial's editor workflow feeds straight into it.

Padding, frame size and the questions people ask

A few things that trip people up the first time:

• What frame size should I use? Keep it uniform. 16×16 and 32×32 are the common pixel-character sizes; every frame in one sheet must match so the grid stays honest. Different animations can use different sizes — just keep each sheet internally consistent.
• Do I need padding between frames? For pixel art rendered at integer scales with nearest-neighbour (point) filtering, tight packing is usually fine. A 1–2 px gap or edge extrusion helps prevent neighbouring frames bleeding in when a frame is drawn at a non-integer scale. Since the atlas stores exact rectangles, your engine samples the right pixels either way.
• Does the sheet need to be a power of two? Modern engines don't require it. Power-of-two dimensions are a harmless old habit for maximum GPU compatibility, not a rule you have to follow.
• What's in the metadata? Per frame: its rectangle and duration. Per sheet: the overall size (and scale). That's what lets an importer rebuild the animation exactly, in order and at the right speed.

Drop it into your engine

The sheet and atlas are engine-ready. Concisely, per engine:

• Unity — import the PNG and slice it in the Sprite Editor (uniform grid or from the atlas rects).
• Godot — load the sheet and read the frames into a SpriteFrames / AnimatedSprite2D. We go deeper on this — H/V frames, SpriteFrames and AnimationPlayer — in making sprite sheets for Godot.
• Phaser — feed the atlas JSON directly to the loader and play by frame names.
• Pixi — hand the atlas to the loader and pull textures by frame key.

For the fuller picture across engines — canvas sizes, grid-true export and import guidance — see making pixel art for your game engine. None of this replaces your engine's own import step; the point is that Tsubu hands off a sheet and atlas that fit the shapes these engines already understand.

Make your first sheet

That's the whole loop: draw or generate your frames, animate them on the timeline, and export a packed sheet plus a JSON atlas that slots into your project. The fastest way to learn it is to make one.

Open the editor and build your first sprite sheet — it's free while we're in early access. Prefer to follow along by email? New workflow guides land on the RSS feed.

If you make games, you know the gap that usually sits in the middle. You draw in one tool, wrangle frames in another, hand-pack a sprite sheet, hand-write an atlas, and pray the coordinates line up. Tsubu closes that gap. It is one place to draw, animate, generate, and export — no install, nothing to lose, and free while we're in early access.

Made for the person shipping the game

Tsubu is not a toy pixel painter. It is a keyboard-first editor with the tools you reach for a hundred times a day — pencil, eraser, fill, eyedropper, select & move — plus a real palette workflow so a whole tileset or character roster stays consistent. Grids go up to 256×256, square or not, because your UI icons and your boss sprites don't live at the same size.

Everything is saved to the cloud and reachable from any browser. Start a walk cycle on the studio desktop; fix a stray pixel from a laptop on the train. Sign in with Google and your library is just there.

From a text prompt to editable pixels

Sometimes you need a first pass, fast. Describe what you want — "a tiny knight with a red cape", "a 16×16 potion bottle" — and Tsubu's AI drafts a finished sprite in the proportions and palette discipline of real pixel art. Readable silhouettes, limited palettes, clean outlines. Not a noisy, downscaled photo.

The important part: what you get back is real pixel data on your canvas, not a flattened image. Every cell is editable. Recolor the cape, fix an outline, redraw a limb. The AI gives you a strong starting grain; you grow the sprite from there.

Animation that stays honest

Build walk cycles, idle bobs and attacks on a filmstrip timeline. Duplicate and reorder frames, preview the loop at your chosen FPS, and keep every frame as plain, editable pixels — never baked, never locked.

The part that usually hurts: export

This is where Tsubu earns its place in your pipeline. Export an animation as a single packed PNG plus a JSON atlas in the familiar Aseprite / TexturePacker shape — frame rects, durations and metadata included. It drops straight into the engines you already use:

• Unity — slice it in the Sprite Editor
• Godot — load the sheet and atlas
• Phaser and PixiJS — feed the atlas directly

Need a still? Export a clean, scaled PNG (1×–8×) with transparency preserved. Need a quick share? Animated GIF, one click.

Free while we're in early access

The whole studio — editor, animation, AI generation and export — is free for early adopters for a limited time, with usage sponsored by the platform. No credit card. No catch. Try it on your current game jam; it costs nothing but the time to draw your first grain.

Start now — it's free, or read more about generating pixel art with AI and making sprites for your game engine.

We're building Tsubu in the open, and this blog is where the workflow tips, sprite breakdowns and product updates will land. Subscribe to the RSS feed and start with a single grain.