pixel-art-sprites

Use this skill when creating pixel art sprites, animating sprite sheets, building tilesets for 2D games, or managing indexed color palettes. Triggers on pixel art, sprite sheet, sprite animation, tileset, tile map, pixel palette, indexed color, dithering, sub-pixel animation, NES palette, walk cycle sprite, and any task involving low-resolution raster art for games or retro aesthetics.

What is pixel-art-sprites?

Overview Files

pixel-art-sprites

pixel-art-sprites is a production-ready AI agent skill for claude-code, gemini-cli, openai-codex. Creating pixel art sprites, animating sprite sheets, building tilesets for 2D games, or managing indexed color palettes.

Quick Facts

Field	Value
Category	design
Version	0.1.0
Platforms	claude-code, gemini-cli, openai-codex
License	MIT

How to Install

Make sure you have Node.js installed on your machine.
Run the following command in your terminal:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill pixel-art-sprites

The pixel-art-sprites skill is now available in your AI coding agent (Claude Code, Gemini CLI, OpenAI Codex, etc.).

Overview

A practical guide to creating pixel art sprites, animating them for games, building reusable tilesets, and managing constrained color palettes. This is not general digital art advice - it focuses on the specific technical and aesthetic constraints of low-resolution raster art where every pixel is a deliberate design decision.

Pixel art looks simple but punishes sloppiness. A single misplaced pixel breaks a silhouette, a wrong hue muddies readability at 1x scale, and an animation with inconsistent volume destroys the illusion of life. This skill covers the rules that prevent those failures.

Platforms

claude-code
gemini-cli
openai-codex

Related Skills

Pair pixel-art-sprites with these complementary skills:

Frequently Asked Questions

What is pixel-art-sprites?

How do I install pixel-art-sprites?

Run npx skills add AbsolutelySkilled/AbsolutelySkilled --skill pixel-art-sprites in your terminal. The skill will be immediately available in your AI coding agent.

What AI agents support pixel-art-sprites?

This skill works with claude-code, gemini-cli, openai-codex. Install it once and use it across any supported AI coding agent.

Maintainers

@maddhruv

Generated from AbsolutelySkilled

SKILL.md

Pixel Art Sprites

When to use this skill

Trigger this skill when the user:

Wants to create a pixel art character sprite or object
Needs to build a sprite sheet with animation frames
Asks about walk cycles, attack animations, or idle animations in pixel art
Wants to design a tileset for a 2D tile-based game
Needs help choosing or constraining a pixel art color palette
Asks about dithering techniques or anti-aliasing in pixel art
Wants to export sprites for a game engine (Unity, Godot, Phaser)
Asks about sub-pixel animation or pixel-perfect rendering

Do NOT trigger this skill for:

High-resolution digital painting, vector illustration, or 3D modeling
General game design questions not related to sprite art (use system-design or gamedev skills)

Key principles

Every pixel is intentional - At 16x16 or 32x32 resolution, there is no room for ambiguity. Each pixel must serve the silhouette, shading, or detail. If removing a pixel does not hurt readability, it should not be there. Start with the silhouette (solid fill), then add internal detail only where it improves recognition at 1x zoom.
Constrain your palette ruthlessly - Limiting colors to 8-16 is not a nostalgic affectation - it enforces visual cohesion across all sprites in a project. Pick a palette before drawing the first sprite. Every color in the palette must have a clear role: base, shadow, highlight, outline, and at most 2-3 accent hues. Adding a color mid-project breaks consistency.
Animate volume, not lines - Beginners animate by shifting outlines. Good sprite animation preserves the volume (total pixel mass) of the character across frames. A walk cycle should not make the character appear to grow and shrink. Check by toggling between frames rapidly - the silhouette should feel stable.
Tiles must be seamless at every edge - A tileset that looks good in isolation but produces visible seams when repeated has failed its only job. Design tiles from the edges inward: lock the border pixels first, then fill the interior. Test with a 3x3 grid of the same tile before considering it done.
Respect the grid - Pixel art lives on a strict grid. Rotation by non-90-degree angles, non-integer scaling, and sub-pixel positioning in engines all destroy pixel crispness. Export at 1x and scale with nearest-neighbor interpolation only. Configure the game engine's texture filter to "point/nearest" not "bilinear".

Core concepts

Sprite sizes and common canvases

Size	Use case	Notes
8x8	Small items, tiny icons, minimal tiles	NES-era constraint
16x16	Standard characters, items, basic tiles	Most common indie size
32x32	Detailed characters, large tiles	Good balance of detail and constraint
48x48 / 64x64	Boss sprites, detailed portraits	Approaches illustration territory

A character sprite sheet typically uses one fixed canvas per frame. All frames in an animation must share the same canvas size to prevent jitter during playback.

Anatomy of a sprite sheet

A sprite sheet is a single image containing all animation frames laid out in a grid. Each row is usually one animation state (idle, walk, attack). Each column is one frame in that animation.

[idle-0][idle-1][idle-2][idle-3]
[walk-0][walk-1][walk-2][walk-3][walk-4][walk-5]
[attack-0][attack-1][attack-2][attack-3]

The game engine slices the sheet by cell size (e.g., 32x32) and plays frames in sequence. Metadata (frame count per row, frame duration) is defined in the engine, not the image.

Tileset structure

Tilesets use a fixed grid (usually 16x16 or 32x32 per tile). Standard tileset categories:

Ground - grass, dirt, stone, water (need seamless tiling)
Edges/transitions - where two terrain types meet (requires 47 auto-tile variants for full coverage, or 16 for simplified)
Decoration - flowers, rocks, signs (placed on top of ground tiles)
Walls/obstacles - collision-relevant tiles

Color ramp anatomy

A color ramp is a sequence of 3-5 colors from shadow to highlight for a single hue:

[dark shadow] -> [shadow] -> [base] -> [highlight] -> [bright highlight]

Each step shifts not just lightness but also hue. Shadows shift toward cool (blue/purple). Highlights shift toward warm (yellow/white). This "hue shifting" creates vibrant, natural-looking shading that flat lightness scaling cannot achieve.

Common tasks

Create a character sprite with proper shading

Start with silhouette, then layer shading using a 3-4 step color ramp with hue shifting.

Workflow:

Draw the silhouette as a solid color block on transparent background
Verify the silhouette is readable at 1x zoom - if you cannot tell what it is, redesign
Pick a base color, then create the ramp: shadow (darker + hue shift cool), base, highlight (lighter + hue shift warm)
Apply light source from top-left (convention in 2D games) - upper-left edges get highlight, lower-right edges get shadow
Add the darkest outline color on exterior edges only; interior lines use the shadow color, not black

Never use pure black (#000000) for outlines. Use a very dark, slightly saturated color (e.g., dark navy or dark brown) that complements the palette. Pure black creates a harsh, flat look.

Build a walk cycle animation

A standard walk cycle uses 4-6 frames. The key poses are: contact, passing, and their mirrors.

4-frame walk cycle:

Frame 1 (Contact) - Front leg extended forward, back leg extended back, body at lowest point
Frame 2 (Passing) - Legs cross under body, body at highest point (1-pixel vertical bob)
Frame 3 (Contact mirrored) - Opposite leg forward
Frame 4 (Passing mirrored) - Mirror of frame 2

Rules:

Maintain consistent volume across all frames - the character should not grow or shrink
Add 1-pixel vertical bob on passing frames (body rises slightly when weight is on one leg)
Arms swing opposite to legs
Frame timing: 100-150ms per frame for a natural pace

Design a seamless tileset

Edge-first workflow:

Define the tile size (16x16 is standard)
Draw the left and top edges first
Copy left edge to right edge, top edge to bottom edge (guarantees seamless)
Fill the interior with detail, avoiding patterns that create obvious repetition
Test by placing 5x5 copies of the tile side-by-side
Add 2-3 variations of the same tile to break repetition in the map

Terrain transitions (auto-tiling):

Simplified: 16 tiles per transition (4-bit bitmask for cardinal neighbors)
Full: 47 tiles per transition (8-bit bitmask for cardinal + diagonal neighbors)
Draw the inner corners, outer corners, and straight edges; the engine handles placement via bitmask lookup

Build and manage a color palette

Step 1: Choose constraints

Total colors: 8 (minimal), 16 (standard), 32 (detailed)
Decide if you are emulating a hardware palette (NES: 54 colors, Game Boy: 4 shades, PICO-8: 16 fixed)

Step 2: Build ramps

For each major hue in your game (skin, foliage, metal, sky), create a 3-5 step ramp
Apply hue shifting: shadows lean toward blue/purple, highlights lean toward yellow/orange
Include one dedicated outline color (near-black, slightly warm or cool depending on mood)

Step 3: Test across all sprites

Every sprite in the game must use only palette colors
If a new sprite needs a color not in the palette, reconsider the design before adding the color
Export the palette as a .pal, .gpl (GIMP), or .png swatch strip for tool import

Example 16-color palette structure:

[outline] [skin-shadow] [skin-base] [skin-highlight]
[hair-shadow] [hair-base] [green-shadow] [green-base]
[green-highlight] [blue-shadow] [blue-base] [brown-shadow]
[brown-base] [gray-base] [white] [accent]

Apply dithering for smooth gradients

Dithering uses alternating pixel patterns to simulate colors between two palette entries. Use sparingly - overdithering makes sprites look noisy.

Common dithering patterns:

Checkerboard (50%) - alternating pixels of two colors; strongest blend
25% / 75% - every 4th pixel is the secondary color; subtle transition
Stylized/organic - irregular pattern that follows the shape's contour

When to dither:

Large flat areas that need subtle gradation (sky backgrounds, large terrain)
Transitions between two ramp colors when adding an intermediate color would bust the palette

When NOT to dither:

Small sprites (16x16 or below) - there are not enough pixels for dithering to read
Animated sprites - dithering patterns shimmer during motion and look like noise

Export sprites for game engines

For Unity:

Export as PNG with transparent background
Import settings: Filter Mode = Point (no filter), Compression = None, Pixels Per Unit = your tile size
Sprite Mode = Multiple, then use the Sprite Editor to slice by cell size

For Godot:

Export as PNG, import with Filter = Nearest (disable in Import tab)
Use AnimatedSprite2D or AnimationPlayer with SpriteFrames resource
Set texture filter on the project level: Rendering > Textures > Default Texture Filter = Nearest

For Phaser / web:

// Load sprite sheet
this.load.spritesheet('player', 'player.png', {
  frameWidth: 32,
  frameHeight: 32
});

// Create animation
this.anims.create({
  key: 'walk',
  frames: this.anims.generateFrameNumbers('player', { start: 0, end: 5 }),
  frameRate: 8,
  repeat: -1
});

// CRITICAL: set pixel-perfect rendering
game.config.render.pixelArt = true;
// or in Phaser 3 config:
// render: { pixelArt: true }

Create sub-pixel animation

Sub-pixel animation creates the illusion of movement smaller than one pixel by shifting color values rather than pixel positions. Used for smooth, fluid motion in small sprites.

Technique: Instead of moving an eye 1 pixel right (which is a large jump at 16x16), darken the current pixel and lighten the adjacent pixel. The viewer's eye interpolates a half-pixel shift.

Rules:

Only works when the sprite is displayed at integer scale (2x, 3x, 4x)
Requires at least 3 values in the color ramp to create intermediate steps
Most effective for small details: eyes blinking, subtle breathing, water shimmer
Do not use for large movements - it looks blurry instead of smooth

Anti-patterns

Mistake	Why it fails	What to do instead
Using bilinear filtering on pixel art	Blurs pixels into a mushy mess, destroys crispness	Always use nearest-neighbor / point filtering in engine and export
Pillow shading (light from all sides)	Creates a flat, blobby look with no directional light	Pick one light direction (top-left is standard) and shade consistently
Too many colors without a palette	Sprites look inconsistent, cannot be themed or recolored	Lock a palette of 8-16 colors before drawing; every sprite shares it
Black outlines everywhere	Creates a dark, heavy look; interior details drown	Use dark saturated colors for outlines; softer colors for interior lines
Jagged curves (staircase lines)	Lines look rough and unintentional	Use consistent pixel-length steps: 3-3-2-2-1 not 3-1-2-4-1 for curves
Non-integer scaling (1.5x, 3.5x)	Pixels become different sizes, grid breaks	Scale only by whole integers: 1x, 2x, 3x, 4x
Animating without consistent volume	Character appears to inflate/deflate between frames	Overlay frames at 50% opacity to check silhouette stability

Gotchas

Exporting with transparency to JPEG destroys it - JPEG does not support alpha channels. Exporting a sprite with transparent background to JPEG fills the transparency with white (or black depending on the tool). Always export sprites as PNG. If a tool auto-selects JPEG, override it.
Unity's default texture filter is Bilinear, not Point - When you import a sprite sheet into Unity, the default Filter Mode is Bilinear, which blurs pixels. You must change it to Point (no filter) in the Texture Import Settings for every sprite. Setting it per-sprite is tedious; configure the default texture filter in the project settings or use an AssetPostprocessor to enforce Point filtering on import.
Non-integer pixel-per-unit settings cause sub-pixel jitter during movement - If your sprite is 16x16 and you set Pixels Per Unit to 32 (not 16), the sprite renders at 0.5 Unity units. Movement in increments smaller than 1/32 of a unit causes the sprite to render between pixel boundaries, producing visible jitter. Set Pixels Per Unit to match your tile size exactly.
Animation frames with different canvas sizes cause jitter in all engines - If walk frame 1 is 32x32 but walk frame 3 is accidentally 32x33 due to a slip in the art tool, the sprite will shift 1 pixel vertically on that frame. Every frame in an animation must share identical canvas dimensions. Check canvas size consistency before exporting a sprite sheet.
Palette colors sampled with anti-aliasing enabled produce off-palette colors - If you draw with any anti-aliasing or smoothing enabled in your art tool (even a small amount), edge pixels blend with surrounding colors and produce hundreds of near-palette colors that are not in the palette. Always draw with hard-edge (aliased) brushes only and verify the final image contains only palette-exact color values.

References

For detailed content on specific sub-domains, read the relevant file from the references/ folder:

references/palette-recipes.md - Pre-built palette recipes for common game genres (fantasy RPG, sci-fi, horror, Game Boy, NES)
references/animation-techniques.md - Advanced animation guides: anticipation, follow-through, squash-and-stretch at pixel scale
references/tileset-patterns.md - Auto-tile bitmask tables, terrain transition templates, and tileset organization patterns

Only load a references file if the current task requires it - they are long and will consume context.

References

animation-techniques.md

Animation Techniques

Advanced sprite animation beyond basic frame sequencing. Covers the 12 principles of animation adapted for pixel art constraints, common animation types with frame breakdowns, and timing tables.

The 12 principles adapted for pixel art

Not all classic animation principles apply at pixel scale. Here is what matters and what to skip.

Principles that matter at pixel scale

Timing and spacing - The most important principle. Frame count and duration per frame control whether motion feels snappy or sluggish. A 3-frame attack reads as fast. A 6-frame attack reads as heavy. Vary frame duration within an animation: hold key poses longer (150-200ms), transition frames shorter (80-100ms).
Anticipation - Before a big action, show a small reverse motion. Before a jump, the character crouches 1-2 pixels. Before a sword swing, the arm pulls back. Even 1 frame of anticipation makes actions feel intentional.
Follow-through and overlapping action - After the main action completes, secondary elements keep moving. Hair trails behind a dash. A cape settles after landing. At pixel scale, this means 1-2 extra frames where accessories or clothing catch up to the body.
Squash and stretch - At 16x16, you cannot literally squash a character. Instead, use 1-pixel height changes: compress 1px before a jump (squash), stretch 1px at peak height. Even this tiny change reads as weight and elasticity.
Ease in / ease out - Do not move at constant speed. Accelerate into an action (ease in) and decelerate out (ease out). Implement by having smaller pixel movements at the start and end, larger in the middle.

Principles to deprioritize

Arcs - Hard to achieve with 1-pixel movement resolution. Focus on straight paths.
Secondary action - Useful but expensive in frame count. Reserve for hero animations.
Appeal - Important in design phase, not animation phase.
Solid drawing - Not applicable; pixel art is 2D by definition.

Common animation types

Idle animation (2-4 frames)

Purpose: show the character is alive when standing still.

Frame 1 (200ms): base pose
Frame 2 (200ms): slight bob - body shifts 1px down, or chest expands 1px
Frame 3 (200ms): return to base (can be same as frame 1)
Frame 4 (200ms): slight bob up, or blink (eyes close for 1 frame)

Keep idle subtle. Large idle movements make the character feel restless.

Walk cycle (4-6 frames)

The 4-frame walk is the most common and efficient:

Frame 1 (120ms): Contact - right foot forward, left back, body at low point
Frame 2 (120ms): Passing - legs crossing under body, body at high point (+1px)
Frame 3 (120ms): Contact (mirror) - left foot forward, right back, body low
Frame 4 (120ms): Passing (mirror) - legs crossing, body high (+1px)

6-frame walk adds in-between frames for smoother motion:

Frame 1 (100ms): Right contact
Frame 2 (100ms): Right recoil (weight settling)
Frame 3 (100ms): Right passing
Frame 4 (100ms): Left contact
Frame 5 (100ms): Left recoil
Frame 6 (100ms): Left passing

Critical rules:

Body bobs 1px up on passing, 1px down on contact (not more)
Arms swing opposite to legs
Total volume must stay constant - overlay all frames to verify

Run cycle (6-8 frames)

Same key poses as walk but with added flight phase (both feet off ground):

Frame 1 (80ms):  Contact - front leg extended, back leg pushing off
Frame 2 (80ms):  Push-off - back leg drives body forward, body leans
Frame 3 (80ms):  Flight - both feet off ground, body at highest point (+2px)
Frame 4 (80ms):  Contact (mirror)
Frame 5 (80ms):  Push-off (mirror)
Frame 6 (80ms):  Flight (mirror)

Faster frame rate than walk (80ms vs 120ms). More exaggerated lean. Body rises 2px on flight (vs 1px walk bob).

Attack animation (3-6 frames)

Three-phase structure: anticipation, action, recovery.

Light attack (3 frames):

Frame 1 (100ms): Anticipation - arm pulls back, body leans away from target
Frame 2 (60ms):  Strike - arm extends, weapon at full reach (shortest frame)
Frame 3 (120ms): Recovery - arm returns, body resets

Heavy attack (6 frames):

Frame 1 (150ms): Wind-up - weapon raised high, body coils (hold this long)
Frame 2 (80ms):  Transition - weapon starts moving
Frame 3 (40ms):  Impact - weapon at contact point (fastest frame)
Frame 4 (40ms):  Follow-through - weapon continues past target
Frame 5 (100ms): Settle - weapon slows
Frame 6 (120ms): Recovery - return to idle

Key insight: The strike/impact frame must be the shortest (40-60ms). The eye fills in the motion. If you hold the impact frame too long, the attack feels slow.

Jump animation (4-5 frames)

Frame 1 (100ms): Crouch (anticipation) - body compresses 1-2px
Frame 2 (80ms):  Launch - legs extend, body at ground level
Frame 3 (hold):  Airborne - arms up, legs tucked (loop this while in air)
Frame 4 (80ms):  Descend - legs extend downward
Frame 5 (120ms): Land - body compresses on impact (squash), dust particles optional

The airborne frame is held for variable duration based on jump height. Do not loop multiple airborne frames - one held frame reads better than a cycling animation in midair.

Death animation (4-6 frames)

Frame 1 (100ms): Hit reaction - body recoils in direction of hit
Frame 2 (100ms): Stagger - off-balance pose
Frame 3 (120ms): Collapse - body falling
Frame 4 (150ms): Grounded - flat on ground
Frame 5 (200ms): Fade or flash (if using death effect)

Hold the final frame longest. Slow the timing toward the end to create a sense of finality.

Frame timing reference table

Animation	Frames	ms/frame	Total duration	Loop
Idle	2-4	150-250ms	400-800ms	Yes
Walk	4-6	100-150ms	400-600ms	Yes
Run	6-8	70-100ms	420-600ms	Yes
Light attack	3-4	40-120ms	200-350ms	No
Heavy attack	5-7	40-200ms	400-700ms	No
Jump (grounded)	4-5	80-120ms	320-500ms	No
Death	4-6	100-200ms	500-900ms	No
Hit/flinch	2-3	60-100ms	120-250ms	No

Sub-pixel animation

Sub-pixel animation creates the illusion of movement smaller than 1 pixel by shifting brightness between adjacent pixels.

How it works

To move a white dot half a pixel right on a black background:

Frame 1:  [100%] [  0%]     - dot is on left pixel
Frame 2:  [ 50%] [ 50%]     - perceived position is between pixels
Frame 3:  [  0%] [100%]     - dot is on right pixel

The "50%" values use intermediate colors from the palette - not transparency. This requires at least 3 brightness steps in the ramp.

Where to use sub-pixel animation

Eyes: blinking, looking left/right (2-3px eyes benefit enormously)
Water shimmer: surface highlights that drift sub-pixel
Breathing: chest or body that rises less than 1 full pixel
Floating objects: gems, particles that hover with micro-movement

Where NOT to use

Movement that exceeds 1 pixel per frame (use real movement instead)
Sprites that will be displayed at non-integer scales (sub-pixel breaks)
Sprites smaller than 8x8 (not enough adjacent pixels to shift between)

Onion skinning workflow

Onion skinning shows previous/next frames as transparent overlays while drawing.

Enable onion skin in your editor (Aseprite: View > Onion Skinning)
Set previous frames to blue tint, next frames to red tint
Show 1-2 frames in each direction (more than 2 creates visual clutter)
Draw the current frame, using the overlay to maintain volume consistency
Disable onion skin periodically and play the animation to check feel

Animation export checklist

All frames are the same canvas size (no frame is taller/wider than others)
Background is transparent (or a consistent chroma key color)
Frames are arranged in a grid (rows = states, columns = frames)
No sub-pixel anti-aliasing on sprite edges (nearest-neighbor only)
Frame timing data is documented (which frames hold longer)
Animation loops cleanly (last frame transitions smoothly to first for looping anims)
Tested at 1x, 2x, and target display scale

palette-recipes.md

Palette Recipes

Pre-built palette structures for common game genres and hardware emulation. Each recipe defines the color roles and hex values ready for import into Aseprite, Piskel, or any tool that accepts .hex/.gpl palettes.

Palette design principles

Hue shifting

Never shade by adding black or white. Shift hue as you change value:

Shadows: shift hue toward blue/purple (cool)
Highlights: shift hue toward yellow/orange (warm)

This creates vibrant, lively colors. Pure value scaling produces dead, muddy tones.

Ramp construction

A single-hue ramp has 3-5 entries:

Step 1 (darkest shadow):  low value, high saturation, cool hue shift
Step 2 (shadow):          medium-low value, medium saturation
Step 3 (base):            medium value, medium saturation, true hue
Step 4 (highlight):       medium-high value, lower saturation, warm hue shift
Step 5 (bright):          high value, low saturation, warm hue shift

Reduce saturation as you approach white - pure saturated highlights look neon and unnatural.

Fantasy RPG palette (16 colors)

Best for: medieval fantasy, dungeon crawlers, adventure games.

Outline:        #1a1a2e
Skin shadow:    #8b5e3c
Skin base:      #d4a574
Skin highlight: #f2d8b8
Hair dark:      #3d2b1f
Hair light:     #6b4c36
Green shadow:   #2d5a27
Green base:     #4a8c3f
Green light:    #7bc96a
Blue shadow:    #2a3f6e
Blue base:      #4a7ec9
Brown shadow:   #4a3728
Brown base:     #7a6045
Gray:           #8e8e9a
White:          #e8e4df
Gold accent:    #d4a017

Use the green ramp for foliage, the brown ramp for wood/leather, blue for water/sky/magic.

Sci-fi palette (16 colors)

Best for: space games, cyberpunk, futuristic UI elements.

Void:           #0a0a1a
Dark panel:     #1c1c3a
Panel base:     #2e2e5c
Panel light:    #4a4a8c
Glow shadow:    #1a4a4a
Glow base:      #2ae6c8
Glow bright:    #7affef
Alert red:      #e63946
Alert dim:      #8c2430
Warm metal:     #9a8866
Cool metal:     #6a7a8e
Metal highlight:#b8c8d8
Skin shadow:    #6a4e3a
Skin base:      #c49a6c
White:          #e0e8f0
Orange accent:  #ff8c42

Emphasize high contrast between dark backgrounds and neon glows. Keep metal desaturated.

Horror/dark palette (12 colors)

Best for: horror, gothic, dark atmosphere games.

Deep black:     #0d0d12
Dark purple:    #1f1428
Blood shadow:   #4a1a1a
Blood base:     #8c2e2e
Rust:           #6a4430
Skin pale:      #c8b098
Skin sickly:    #a89878
Gray cold:      #4a4e58
Gray light:     #7a7e88
Bone:           #d8d0c0
Eye glow:       #c8e038
Fog:            #b8b8c8

Restrict the palette to muted, desaturated tones. The single bright accent (eye glow) draws focus.

Game Boy (4 shades)

Emulates the original Game Boy's 4-shade green LCD.

Darkest:        #0f380f
Dark:           #306230
Light:          #8bac0f
Lightest:       #9bbc0f

All sprites, backgrounds, and UI must work within these 4 values. Forces extreme clarity in silhouette design.

NES-style palette (25 colors, selected from the NES 54-color master)

The NES hardware could display 25 colors simultaneously (4 palettes of 4 colors + shared background). This selection covers most game needs:

Background:     #0f0f0f  (shared black)

Palette 0 (character):
  #7c1f22  #d45040  #f8a060  #fce8c0

Palette 1 (environment):
  #1a3a1a  #30782e  #68b840  #b8f878

Palette 2 (sky/water):
  #0c2060  #2060c0  #4898f8  #a8d8f8

Palette 3 (UI/accent):
  #601080  #a040c0  #e078f0  #f8f8f8

Each palette group must include a shadow, midtone, highlight, and bright value.

PICO-8 fixed palette (16 colors)

The PICO-8 fantasy console uses a fixed 16-color palette. Many pixel artists use it as a constraint even outside PICO-8.

 0: #000000  black         8: #ff004d  red
 1: #1d2b53  dark blue     9: #ffa300  orange
 2: #7e2553  dark purple  10: #ffec27  yellow
 3: #008751  dark green   11: #00e436  green
 4: #ab5236  brown        12: #29adff  blue
 5: #5f574f  dark gray    13: #83769c  lavender
 6: #c2c3c7  light gray   14: #ff77a8  pink
 7: #fff1e8  white        15: #ffccaa  peach

The PICO-8 palette is well-balanced for general purpose pixel art. Use it as-is for jam games or as a starting template.

Building custom palettes

Method 1: Ramp-first

Decide how many distinct hues you need (usually 3-5)
For each hue, build a 3-4 step ramp with hue shifting
Add one outline color (near-black, slightly tinted)
Add one near-white highlight
Total: (hues x ramp_steps) + 2

Method 2: Reference-first

Find a screenshot or photo with the mood you want
Sample 4-6 dominant colors
Build ramps around each sampled color
Adjust for contrast - ensure darkest and lightest values are far enough apart

Method 3: Tool-assisted

Lospec Palette List (lospec.com/palette-list) - browse thousands of curated palettes
Aseprite palette editor - built-in ramp generation with hue shift
Color Ramp Generator (pixelparmesan.com/color-ramp-generator) - web tool for hue-shifted ramps

Palette file formats

Format	Extension	Used by
GIMP Palette	.gpl	GIMP, Aseprite, LibreSprite
Hex text	.hex	Lospec, web tools
Adobe Color Table	.act	Photoshop
PAL (RIFF)	.pal	Pro Motion, older tools
PNG swatch	.png	Universal - 1px per color in a row

Export as .gpl for maximum compatibility. Most pixel art tools can import .gpl or .hex directly.

tileset-patterns.md

Tileset Patterns

Tileset design patterns, auto-tile bitmask systems, and organization strategies for 2D tile-based games.

Tile sizes

Size	Pros	Cons	Best for
8x8	Tiny file size, retro feel	Very limited detail	NES-style, minimalist games
16x16	Industry standard, good balance	Characters need 16x24+ for readability	Most 2D games, RPGs, platformers
32x32	High detail, readable characters	Larger files, more drawing time	Detailed RPGs, strategy games
48x48	Rich detail	Approaches non-pixel territory	High-res pixel art games

Choose one size for the entire project. Mixing tile sizes creates alignment headaches.

Tileset organization

Standard tileset layout

Organize tiles by function, not by visual similarity:

Row 0:  Ground variants (grass1, grass2, grass3, dirt1, dirt2, stone1...)
Row 1:  Ground edges - grass-to-dirt transitions
Row 2:  Water tiles (still, animated frame 1-3, shore edges)
Row 3:  Walls (top, middle, bottom, left-cap, right-cap, corners)
Row 4:  Decorations (flowers, rocks, signs, chests, barrels)
Row 5:  Interactive (doors, levers, breakable walls)
Row 6:  Special / UI (shadow overlay, highlight, selection indicator)

Tile ID conventions

Assign predictable IDs so the game engine can reference tiles by number:

0:    Empty / transparent
1-10: Ground base tiles
11-26: Ground edge transitions (16 auto-tile variants)
27-30: Water base (animated, 3 frames + still)
31-46: Water edge transitions
47-60: Wall pieces
61+:  Decorations and special

Auto-tiling systems

Auto-tiling automatically selects the correct tile variant based on neighboring tiles. This is what makes terrain transitions seamless.

4-bit (simple) auto-tiling

Check 4 cardinal neighbors (up, right, down, left). Each can be same-type (1) or different-type (0). This gives 2^4 = 16 possible combinations.

Bitmask values:

       UP = 1
LEFT = 8   RIGHT = 2
      DOWN = 4

Bitmask	Neighbors present	Tile type
0	None	Isolated (single tile)
1	Up	Bottom edge
2	Right	Left edge
3	Up + Right	Bottom-left corner
4	Down	Top edge
5	Up + Down	Vertical corridor
6	Right + Down	Top-left corner
7	Up + Right + Down	Left edge (open left)
8	Left	Right edge
9	Up + Left	Bottom-right corner
10	Right + Left	Horizontal corridor
11	Up + Right + Left	Bottom edge (open bottom)
12	Down + Left	Top-right corner
13	Up + Down + Left	Right edge (open right)
14	Right + Down + Left	Top edge (open top)
15	All	Center / interior

This system handles most games well. Diagonal transitions will show visible corners where two terrains meet at a diagonal.

8-bit (full) auto-tiling - Wang tiles / blob tileset

Check all 8 neighbors (4 cardinal + 4 diagonal). This gives 2^8 = 256 combinations, but many are redundant. After eliminating cases where a diagonal only matters if both adjacent cardinals are present, you get 47 unique tiles.

When to use 8-bit:

Terrain transitions need smooth diagonal corners
The game has large open areas where diagonal seams are visible
You need professional-quality terrain blending

When 4-bit is enough:

Small maps or dungeon rooms
Tile transitions are covered by decorative objects
Development time is limited

47-tile breakdown

The 47 tiles cover these categories:

Interior tiles:     1  (all neighbors same)
Edge tiles:         4  (one side exposed)
Outer corners:      4  (two adjacent sides exposed)
Inner corners:      4  (diagonal exposed, both adjacent cardinals same)
Three-side exposed: 4  (only one side has same-type neighbor)
Peninsulas:         4  (narrow 1-tile protrusions)
Combined cases:    26  (various inner + outer corner combos)

Drawing the 47-tile set efficiently

Do not draw 47 tiles from scratch. Use this workflow:

Draw 5 base tiles: full interior, top edge, right edge, inner corner (top-right), outer corner (top-right)
Rotate/mirror to get the 4 directional variants of each
Composite the corner and edge tiles to generate combination tiles
Hand-adjust any composited tiles that look wrong at the seams

Many tile editors (Tilesetter, Auto Tile Gen) automate step 2-3.

Terrain transitions

Two-terrain transition

When grass meets dirt, you need transition tiles. The grass tile is the "primary" (it draws on top), dirt is the "secondary" (it fills gaps).

Approach:

Draw the dirt tile as a complete seamless tile
Draw the grass tile, also seamless
Create transition tiles where grass partially covers dirt
The transition edge should be organic (not a straight line)

Multi-terrain transitions

When 3+ terrains meet (grass, dirt, water), complexity explodes. Strategies:

Layered approach - Assign a draw priority to each terrain. Higher priority terrains draw their edges on top of lower ones. Only need transition tiles between adjacent priority levels.
Corner-based approach - Each tile has 4 corners. Each corner can be any terrain type. Generate tiles for all corner combinations. This scales to n^4 tiles for n terrain types (expensive but complete).
Practical compromise - Define which terrains can be adjacent (grass-dirt yes, grass-lava no). Only create transitions for valid pairs.

Animated tiles

Some tiles need animation: water, lava, torches, grass waving.

Implementation strategies

Strategy 1: Separate animated tileset

Export animated tiles as additional columns in the tileset. The engine swaps tile IDs on a timer.

Tile 27: water-frame-0
Tile 28: water-frame-1
Tile 29: water-frame-2

Engine cycles: 27 -> 28 -> 29 -> 27 (at 200ms intervals).

Strategy 2: Shader-based

For simple animations (color cycling, palette shifting), use a shader that rotates palette indices. No extra tiles needed. Works well for water shimmer and lava glow.

Strategy 3: Overlay sprites

Place animated sprites on top of static tiles. Good for torches, sparkles, smoke. Keeps the tileset simple and animation contained in the sprite system.

Animated tile timing

Tile type	Frames	ms/frame	Notes
Water (calm)	3-4	250-400ms	Slow, rhythmic
Water (rapids)	3-4	100-150ms	Faster cycling
Lava	3-4	200-300ms	Irregular timing adds realism
Torch flame	3-4	120-180ms	Randomize per-torch for variety
Grass sway	2-3	300-500ms	Very subtle, easy to overdo
Waterfall	2-3	80-120ms	Fast, continuous

Tileset export checklist

All tiles are exactly the same size (no off-by-one errors)
No gaps or padding between tiles (or consistent 1px padding if engine requires)
Background color is transparent or documented chroma key
Tile IDs are documented in a map or spreadsheet
Seamless tiles tested in a 3x3+ grid
Transition tiles tested with all valid neighbor combinations
Animated tiles have consistent frame count and timing
Exported at 1x scale (engine handles scaling with nearest-neighbor)
File format is PNG (lossless - never JPEG for pixel art)

Tool-specific tileset setup

Godot (TileMap + TileSet)

Import tileset PNG with texture filter set to Nearest
Create a TileSet resource, set tile size to match your grid
Use the auto-tile feature: paint terrain types onto the tileset
Godot 4 supports the 47-tile blob format natively

Unity (Tilemap)

Import PNG: Sprite Mode = Multiple, Filter = Point, Compression = None
Slice using Sprite Editor at tile size
Create a Tile Palette, drag sliced sprites in
For auto-tiling, use Rule Tiles (Unity 2D Tilemap Extras package)

Tiled (map editor)

Import tileset PNG, set tile dimensions
Define terrain types using the Terrain Editor
Export as JSON or TMX for engine import
Tiled supports Wang tile sets for 8-bit auto-tiling

Common tileset mistakes

Mistake	Result	Fix
Tiles not truly seamless	Visible grid lines in the map	Test every tile in a 5x5 repeated grid
Inconsistent lighting direction	Some tiles lit from left, others from right	Establish light direction before drawing any tile
Too much detail in repeating tiles	Obvious pattern repetition in large areas	Create 3-4 variants and randomize placement
Forgetting collision data	Pretty tiles but broken gameplay	Define collision shapes alongside visual tiles
JPEG export	Compression artifacts destroy pixel art	Always export as PNG (lossless)

Frequently Asked Questions

What is pixel-art-sprites?

How do I install pixel-art-sprites?

Run npx skills add AbsolutelySkilled/AbsolutelySkilled --skill pixel-art-sprites in your terminal. The skill will be immediately available in your AI coding agent.

What AI agents support pixel-art-sprites?

pixel-art-sprites works with claude-code, gemini-cli, openai-codex. Install it once and use it across any supported AI coding agent.

pixel-art-sprites

What is pixel-art-sprites?

pixel-art-sprites

Quick Facts

How to Install

Overview

Tags

Platforms

Related Skills

Frequently Asked Questions

What is pixel-art-sprites?

How do I install pixel-art-sprites?

What AI agents support pixel-art-sprites?

Maintainers

SKILL.md

Pixel Art Sprites

When to use this skill

Key principles

Core concepts

Sprite sizes and common canvases

Anatomy of a sprite sheet

Tileset structure

Color ramp anatomy

Common tasks

Create a character sprite with proper shading

Build a walk cycle animation

Design a seamless tileset

Build and manage a color palette

Apply dithering for smooth gradients

Export sprites for game engines

Create sub-pixel animation

Anti-patterns

Gotchas

References

References

animation-techniques.md

Animation Techniques

The 12 principles adapted for pixel art

Principles that matter at pixel scale

Principles to deprioritize

Common animation types

Idle animation (2-4 frames)

Walk cycle (4-6 frames)

Run cycle (6-8 frames)

Attack animation (3-6 frames)

Jump animation (4-5 frames)

Death animation (4-6 frames)

Frame timing reference table

Sub-pixel animation

How it works

Where to use sub-pixel animation

Where NOT to use

Onion skinning workflow

Animation export checklist

palette-recipes.md

Palette Recipes

Palette design principles

Hue shifting

Ramp construction

Fantasy RPG palette (16 colors)

Sci-fi palette (16 colors)

Horror/dark palette (12 colors)

Game Boy (4 shades)

NES-style palette (25 colors, selected from the NES 54-color master)

PICO-8 fixed palette (16 colors)

Building custom palettes

Method 1: Ramp-first

Method 2: Reference-first

Method 3: Tool-assisted

Palette file formats

tileset-patterns.md

Tileset Patterns

Tile sizes

Tileset organization

Standard tileset layout

Tile ID conventions

Auto-tiling systems

4-bit (simple) auto-tiling

8-bit (full) auto-tiling - Wang tiles / blob tileset

47-tile breakdown