How to Make a Sprite Sheet: A Practical Guide for Solo Devs

A sprite sheet is one image holding every frame of an animation, laid out in a row or a grid. Your engine draws a window over one cell at a time, steps the window along, and the character walks.

The reason to bother — instead of shipping eight separate PNGs — is that the GPU binds one texture instead of eight. On a 2D game with forty animated entities on screen, that difference shows up in the frame time. It also means one file to version, one file to swap when the art direction changes.

The format is settled. What isn’t settled, and what people get wrong, is the handful of numbers you pick before you start.

Frame count: 6, 8, or 12

This is the decision that most changes how the animation feels, and it’s the one people default on.

6 frames is enough for a walk cycle if the character has simple legs and the game reads at a distance. It’s also the cheapest to iterate on. Top-down RPGs where the sprite is 32px tall have shipped on 4 frames for decades and nobody noticed.

8 frames is the workhorse. Contact, down, pass, up — twice, mirrored. It gives you a proper weight shift, and it divides cleanly if you later want to drop to 4 for a lower-detail LOD.

12 frames starts to look like animation rather than motion. Use it when the character is large on screen, when there’s a cape or hair that needs to trail, or when the action is a one-shot the player will watch — a death, a spell cast, a transformation. On a walk cycle that loops for six hours of playtime, twelve frames is mostly wasted work.

A rule that holds up: if the loop plays constantly, spend your frames on readability. If it plays rarely, spend them on smoothness.

Cell size: pick from the engine backwards

Cell size is the pixel dimensions of a single frame. Common choices are 16, 32, 64, 96, and 128.

Don’t pick this by “how detailed I want it to look.” Pick it by how many pixels the sprite will actually occupy on the player’s screen.

Take a 1920x1080 target. If your camera shows 30 tiles across, each tile is 64 screen pixels. A character that stands one-and-a-half tiles tall wants roughly 96 pixels of art. Authoring at 32 and scaling up 3x gives you the chunky look on purpose; authoring at 128 and scaling down gives you mush, because downscaling pixel art destroys the hard edges that make it pixel art.

The failure mode to avoid is authoring at a size that isn’t an integer multiple of your display size. 32px art at 2x is crisp. 32px art at 2.4x has a shimmer on every diagonal, and it will bother you forever once you see it.

If you’re not doing pixel art at all — if you want a smooth, high-resolution character — that’s a different pipeline, and the cell is typically 1024 with the sheet scaled down at runtime.

Perspective changes the whole sheet

Four perspectives cover nearly everything in 2D:

• Top-down — the camera looks straight down. You see the top of the head and the shoulders. Common in twin-stick shooters and roguelikes.
• Side-view — pure profile. Platformers, fighting games, endless runners.
• Isometric — the three-quarter view. More expensive, because a walk cycle usually needs four or eight directions instead of one.
• Grid RPG — the three-quarter-ish view where the character faces the camera but moves on a grid. Reads as top-down but shows the face.

Pick this before you draw a single frame. It’s not a filter you apply afterwards — it determines which limbs are visible, where the shadow falls, and how many directional variants you owe yourself.

Getting it into your engine

Unity. Set the texture’s Sprite Mode to Multiple, open the Sprite Editor, and use Slice → Grid By Cell Size with your cell dimensions. For pixel art, set Filter Mode to Point (no filter) and Compression to None — the default bilinear filter is what makes pixel art look blurry, and it catches everyone once.

Godot. Add an AnimatedSprite2D, create a SpriteFrames resource, and use “Add frames from a Sprite Sheet.” Set the horizontal count to your frame count and vertical to 1 for a single-row sheet. In Project Settings, turn off texture filtering for pixel art.

Phaser. this.load.spritesheet(key, path, { frameWidth: 64, frameHeight: 64 }), then define the animation with this.anims.create(...). Set pixelArt: true in the game config.

All three want the same thing from you: a sheet where every cell is exactly the same size, in one row, with no gaps.

Three things that will bite you

Transparent-edge bleeding. When the GPU samples a pixel at the edge of a cell, bilinear filtering pulls in a neighbouring cell’s pixels, and you get a one-pixel fringe of the wrong colour. Point filtering avoids it. So does a 1–2px transparent gutter around each cell, if your slicing tool supports it.

Inconsistent anchor points. If the character’s feet sit at y=60 in frame 1 and y=58 in frame 5, the sprite bobs while walking. Every frame needs the same ground line. This is the single most common reason a hand-drawn sheet looks amateurish, and it’s invisible until the animation plays.

Non-uniform cells. Trimming each frame to its bounding box seems tidy and breaks grid slicing completely. Keep the cells uniform. Let the empty space be empty.

Where generation fits

Drawing eight consistent frames by hand is a real skill, and it’s the reason most solo devs ship with placeholder art. The bottleneck isn’t the idea — it’s holding a character’s proportions, palette, and silhouette steady across every frame.

That consistency problem is what generation is good at. You describe the character and the action, choose the perspective and cell size, and get a sheet back with the frames already aligned to a uniform grid. It won’t replace an animator on a project that lives or dies by its animation. For getting a prototype playable this weekend, it removes the step that usually stops it.

Whatever you use to make it, the numbers above are the ones to decide first. They’re much cheaper to get right at the start than to fix after you’ve built the animation state machine around them.