Topic hub

Pixel art for games

How to make and adapt sprites, animation, tilesets, and backgrounds for games, from the color and light basics up to a finished sprite sheet.

The problem

You have a game that needs art, and either a purchased asset library that almost fits or a blank canvas. Pixel art looks simple because every mark is a visible square, and that is exactly what makes it hard: there is nowhere to hide. A misplaced pixel reads as a mistake, a color one step too bright breaks a form, and a walk cycle with one bad frame limps forever.

This cluster teaches pixel art the way a game needs it: sprites that read at one-times scale on a phone, animations that loop, tiles that repeat without showing their seams, backgrounds with depth, and export that survives the trip into a game engine. Underneath every technique is a small set of first-year ideas about color, light, projection, and timing, and each of those has its own page. Follow the "Before this" links downward until you land on something you already know, then read back up.

The pipeline

Every page points back to this picture of how a piece of pixel art gets made and shipped.

Stage Question it answers Techniques that live here
1. Decide the rules What resolution, palette, view, and light direction does this game use? Pixel art fundamentals, Palettes and ramps, Projections and views
2. Draw the still How does one sprite, tile, or background layer get drawn so it reads? Shading and lighting, Dithering, Anti-aliasing in pixel art, Character design for sprites, Isometric pixel art
3. Make it move How many frames, which poses, what timing? Sprite animation, VFX and particles
4. Build the world How do tiles repeat and backgrounds gain depth? Tileable textures and tilesets, Backgrounds and parallax, UI and text in pixel art
5. Ship it How does the art get into the game intact? Sprite sheets and export, Adapting purchased packs

Stages 1 and 5 are where most avoidable damage happens. A game that never wrote down its rules ends up mixing 16-pixel and 32-pixel characters on the same screen. A game that exports carelessly ends up with blurry sprites and seams between tiles, and the art itself was never at fault.

Which page for which job

You are starting from nothing. Read Pixel art fundamentals, then Palettes and ramps, then Shading and lighting. Those three cover the decisions you cannot undo later: canvas size, color count, and where the light comes from. Character design for sprites is next if your game has a character; Tileable textures and tilesets if it has a world.

You have a purchased pack and it almost fits. Go straight to Adapting purchased packs. It sends you back to Palettes and ramps for recoloring and to Tileable textures for extending a tileset in the pack's own style. The running example across this cluster is a library with two families: side-scroller packs (layered backgrounds plus platform tiles and decor) and top-down tilesets (ground, forest, town, dungeon), some with palette variants for seasons.

Something looks wrong and you do not know why. The usual suspects, in order: mixed pixel sizes (Pixel art fundamentals), pillow shading or banding (Shading and lighting), a palette with no value contrast (Color basics, then Palettes and ramps), and non-integer scaling in the engine (Sprite sheets and export).

Animation feels stiff. Animation timing basics first, then Sprite animation. Almost every stiff walk cycle is a timing problem, not a drawing problem.

Backgrounds look flat. Backgrounds and parallax, which leans on Light and form for atmospheric perspective and on Projections and views for the horizon.

The basics underneath

None of these needs anything beyond first-year college material, and most need less.

You need For
Raster images and pixels What a pixel, an alpha channel, and an indexed palette actually are, and why scaling by 1.5 shimmers.
Color basics Hue, saturation, value, and why value alone decides whether a sprite reads.
Light and form Highlight, midtone, core shadow, reflected light, cast shadow. Every shading page assumes this vocabulary.
Animation timing basics Frames per second, holds, spacing, and the handful of animation principles that pixel art can actually use.
Projections and views Side view, top-down, three-quarter, isometric: what each shows, what each hides.
Tile grids for artists Tile sizes, the grid as a constraint, and what an autotile set asks you to draw.

Conventions used across this cluster

So the pages agree with each other:

  • Light comes from the upper left unless a page says otherwise. Highlights face it, cast shadows fall down and to the right.
  • Sizes are in pixels at one-times scale. A "16-pixel character" is 16 pixels tall on the canvas, however large it is displayed.
  • Scale is always an integer when displayed: 2x, 3x, 4x. The pages say why.
  • A ramp is an ordered list of colors from dark to light used to shade one material. Palettes are made of ramps.
  • Frame timing is given in milliseconds per frame, with the equivalent at 60 frames per second in parentheses where it helps.
  • The running example asset library is the same one the Dynamic map generation cluster uses, so a tile drawn here can be placed by a generator described there.

How to read this cluster

The learning path below is sorted so that each row depends only on the rows above it. If you already draw, skip the foundations and start at Pixel art fundamentals. If you are here to fix a specific pack, start at Adapting purchased packs and follow its links back only as far as you need.

Learning path

Each row depends only on rows above it. Read top to bottom, or jump to a technique and follow its "Before this" links downward.