--- name: pixel-art description: Give a 2D browser game (Phaser or canvas, tile-based) good-looking, consistent pixel art without changing how it plays. Covers art direction, palette, edge-band terrain, a hero and props drawn in code, backgrounds (local image model or procedural), light and checking. Use when the user asks for pixel art, sprites, tiles, a visual style or a makeover, or says the game looks plain, ugly, unfinished or like programmer art. --- # Pixel art Good pixel art in a game comes from a few decisions made once and kept everywhere: one palette, one light direction, one pixel size, and a clear order of what stands out. Make those decisions on one picture of a real room, then draw everything to match. Draw the play layer in code so every room matches. Use an image model only for the scenery behind it. This skill's scripts are in `${CLAUDE_SKILL_DIR}/scripts/` (the references write `` for this folder). The platformer-levels skill sits next to it, at `${CLAUDE_SKILL_DIR}/../platformer-levels/`. ## Always do 1. **Set the direction on one key image first.** Before making any assets, build one mockup of a real room from the game (its actual tile grid) in the chosen direction: background, terrain, hero, a hazard, a pickup and the exit. Take the palette and the value plan from it. Look at it at 1× and 2× and fix the direction until it looks right. Making assets one at a time without a direction gave an ugly, mismatched first pass. See [references/art-direction.md](references/art-direction.md). 2. **Plan values, not just colours.** The background is dark, soft and low contrast. The play layer is mid and clear. The hero and pickups are the brightest things on screen. Danger has its own colour that nothing else uses. Each material gets a ramp of 3–5 hue-shifted shades (darker shades are cooler). Use one light direction (top-left) and outline a shape only where it must stand out from what's behind it. 3. **Terrain is a dark mass with a detailed edge.** Don't fill terrain with blocks. The inside is a dark mass close to the background value, and all detail lives in an uneven band where the player walks: caps that overhang, drips and roots underneath, thin rims on the sides, tapered undersides on floating platforms, with no seams between tiles. `scripts/edge-terrain.js` draws this from a room's grid, behind the game's own collision. Objects the player must recognise keep their own shape in a material that contrasts with the terrain around them: a spring must not be green on green moss, and a crumbling block must look like cracked stone that is about to break, not like a crate. See [references/terrain.md](references/terrain.md). 4. **Draw the play layer in code, scenery with a model.** Terrain, objects, the hero and props are pixel arrays in code, so they look the same in every room. Draw 16 px of art per tile at 2× (bolder pixels look intentional). Use an image model only for backgrounds and organic scenery, reduced to the background colours (`scripts/comfy_bg.py`, local ComfyUI). If there is no image model, draw backgrounds with `scripts/pixel.py procbg` and tell the user. See [references/sprites-and-hero.md](references/sprites-and-hero.md) and [references/backgrounds.md](references/backgrounds.md). 5. **Make an original hero that reads at 1×.** Give it a distinct silhouette and one memorable detail (a scarf, a hood). Build the idle, run, jump and fall frames from shared parts so the face can't change between frames. Swap palettes to show game states (double jump spent). Size it from the hitbox (as wide as the hitbox, feet on the hitbox bottom), and keep it the brightest thing on screen in every state, including the first frames of a room. 6. **Add props and light.** Put a few props in each room, on edges (lanterns, plants, broken pillars), never covering hazards, pickups, exits or the path. Set warm light sources against cool surroundings. Do glow, vignette and particles in code at runtime instead of painting them into the art. Background shapes must never look like platforms: keep them far darker or lighter than the walkable edges, without their caps, and vary them between rooms so the same silhouette doesn't sit behind every room. Goals and exits outrank ordinary doors in brightness and size. See [references/light-and-effects.md](references/light-and-effects.md). 7. **Never change how the game plays.** Leave hitboxes, physics, timers and level data alone, and draw art on separate objects. Hide old shapes instead of removing their physics bodies. Run the game's measurement before and after (platformer-levels `scripts/measure-difficulty.mjs` if the game has it); the results must match exactly. 8. **Check every room and report.** Look at screenshots of every room at 1× and 2×. Hazards, pickups, exits and the HUD must be readable, nothing must cover them, and the player must never appear inside rock. Report the direction and palette, what is drawn in code and what came from the image model (or that no model was used), the before/after measurements, and anything left unfixed. See [references/checking.md](references/checking.md) and the known traps in [references/pitfalls.md](references/pitfalls.md). ## Not now New mechanics, level changes and sound. Leave animated terrain, lighting shaders and more than three parallax layers until the user asks.