Sprite sheets: layout, frame counts and playback
A sprite sheet is one image holding every frame of an animation in a grid, which the engine draws one cell at a time. The layout part is simple. The part that goes wrong is the relationship between frames, and that is most of what this page is about.
Grid layouts
A cell is only square when the sheet's aspect ratio matches its columns over its rows. On a square sheet that means the same number of columns and rows, which is why the useful frame counts are square numbers:
| Frames | Grid | Cell from a 1024px sheet | Typical use |
|---|---|---|---|
| 4 | 2 x 2 | 512 px | Simple loops: idle, a spinning pickup |
| 8 | 3 x 3 | 341 px | The usual choice for a walk or run cycle |
| 16 | 4 x 4 | 256 px | Smooth motion for a main character |
Eight frames is the interesting case. A 4x2 grid would need a 2:1 sheet, so an eight-frame animation is better rendered as 3x3 with the ninth cell discarded: the cells stay square and end up larger than a 4x4 grid would give.
The mistake that ruins most sheets
Never crop or align frames individually. It is the single most common way a technically correct sheet plays back badly, and it is tempting because each frame looks better in isolation afterwards.
The reason is that the motion in an animation is the difference between frames. A walk bobs because the body lifts while the feet stay planted. Re-seating every frame on its own bounding box removes exactly that difference, and because each frame is trimmed independently, a smooth two-pixel wave comes back as noise.
Measuring our own pipeline while this was broken, head position across eight frames ran 21, 56, 30, 43, 42, 51, 29, 45 pixels, with six direction reversals where a two-step cycle should have two. It read as a dance rather than a walk. The fix is to crop every frame with a box of the same size, so per-cell drift is corrected while real vertical motion survives.
What carries the motion depends on the camera
This is not a stylistic preference. The same walk needs different emphasis depending on the view, because some motion is simply not visible from some angles:
| View | What carries the motion |
|---|---|
| Side on (platformer) | The stride. Legs swing wide across the picture plane and the full range is visible. |
| Isometric | A foreshortened stride along the diagonal, plus a bob. |
| Top down / front facing | The vertical bob. The stride points away from the camera, so the legs stay close to the centre line. |
Getting this wrong is visible. Describing a front-facing walk with side-on stride language produced legs snapping between 80 and 244 pixels apart in our own tests: the model drew a stride it could not actually show, so it splayed the legs sideways instead. Emphasising the bob and capping the leg gap took leg variation from 67% down to 5%.
Playback speed
An eight-frame walk cycle is two steps, and a person walks roughly two steps per second, so the cycle should take about 1.0 to 1.3 seconds. That puts it near 6 frames per second. At 10 fps the same cycle finishes in 0.8 seconds and reads as scurrying.
Faster is not automatically smoother. Frame rate should follow what the action would actually take: an attack can be quick, an idle breathing loop is usually slower than people expect.
Checking a sheet actually animates
A sheet can pass every structural check and still be unusable. Correct cell count, no empty cells, real transparency, aligned baselines and a consistent character are all true of sixteen copies of the same pose.
Never judge an animation by one frame. Lay every frame out in sequence and look at the progression, or measure it. A useful numeric check for a side-on walk is the variation in leg spread across frames: a real cycle lands around 40 to 60%, while roughly 15% means the frames are barely moving. For a spin, width variation is the meaningful measure instead, since legs tell you nothing.
Frequently asked questions
- How many frames does a walk cycle need?
- Four frames reads as a walk, eight is the common choice, and sixteen is smooth enough for a hero character. A front-facing cycle is often really four poses with the second half mirrored: contact, passing, contact mirrored, passing mirrored.
- What size should each sprite sheet cell be?
- Every cell must be the same size and square, or frames stretch during playback. What matters is that the sheet's total dimensions divide evenly by the number of columns and rows, so a 1024 x 1024 sheet gives 512px cells at 2x2, 341px at 3x3 and 256px at 4x4.
- Why does my sprite jitter or bounce during playback?
- Almost always because the frames were cropped or aligned individually. The motion in an animation IS the difference between frames, so re-centring each frame on its own bounding box deletes it. Every frame needs a crop box of the same size, positioned consistently, so a walk keeps its vertical bob instead of turning into noise.
- What frame rate should a sprite animation play at?
- Around 6 frames per second suits an eight-frame walk cycle. A person walks roughly two steps a second and an eight-frame cycle is two steps, so it should take about 1.0 to 1.3 seconds. At 10 fps the same cycle finishes in 0.8 seconds and reads as scurrying.
- Should I draw each animation frame separately?
- For AI generation, no. Generating each pose in isolation lets proportions and colours drift between frames, because nothing ties them together. Rendering every frame in one image gives the model shared context, so each cell sees the same character, palette, scale and camera.