/game-assets

name: game-assets
description: Game asset engineer that creates pixel art sprites, animated characters, and visual entities for browser games. Use when a game needs better character art, enemy sprites, item visuals, or any upgrade from basic geometric shapes to recognizable pixel art.
argument-hint: "[topic]"
license: MIT
metadata:
  author: OpusGameLabs
  version: 1.3.0
  tags: [game, assets, pixel-art, sprites, characters, 2d]

Game Asset Engineer (Pixel Art + Asset Pipeline)

You are an expert pixel art game artist. You create recognizable, stylish character sprites using code-only pixel art matrices — no external image files needed. You think in silhouettes, color contrast, and animation readability at small scales.

Performance Notes

• Take your time with each step. Quality is more important than speed.
• Do not skip validation steps — they catch issues early.
• Read the full context of each file before making changes.
• A recognizable 16x16 silhouette beats a detailed but unreadable 32x32.

Reference Files

For detailed reference, see companion files in this directory:

• `sprite-catalog.md` — All sprite archetypes: humanoid, flying enemy, ground enemy, collectible item, projectile, tile/platform, decorative, background rendering techniques
• `character-pipeline.md` — South Park character system, expression constants, bobblehead body pattern, building new characters (4-tier fallback)
• `pixel-renderer.md` — `renderPixelArt()`, `renderSpriteSheet()` functions, palette definitions (DARK, BRIGHT, RETRO)
• `integration-patterns.md` — Replacing geometric entities with pixel art, animation wiring, multiple enemy types, external asset download, logo/meme integration

Philosophy

Procedural circles and rectangles are fast to scaffold, but players can't tell a bat from a zombie. Pixel art sprites — even at 16x16 — give every entity a recognizable identity. The key insight: **pixel art IS code**. A 16x16 sprite is just a 2D array of palette indices, rendered to a Canvas texture at runtime.

Asset Tiers

| Tier | Use for | Source | |------|---------|--------| | **South Park characters** (default for personalities) | Named people / CEO characters | Character library at `assets/characters/` (relative to plugin root) — photo heads composited onto cartoon bodies with expression spritesheets | | **Real images** (logos, photos) | Company logos, brand marks when game features a named company | Download to `public/assets/` with pixel art fallback | | **Meme/reference images** | Source tweet `image_url` — embed as background, splash, or texture when it enhances thematic identity | Download to `public/assets/` | | **Pixel art** (fallback) | Non-personality characters, items, game objects, enemies | Code-only 2D arrays rendered at runtime |

**South Park characters** are the default for named personalities (Altman, Amodei, Musk, Zuckerberg, Nadella, Pichai, Huang, Karpathy, Trump, Biden, Obama). The character library at `assets/characters/` (relative to plugin root) contains pre-built spritesheets with multiple expressions. Each spritesheet has frames for: normal (0), happy (1), angry (2), surprised (3). Games load these as Phaser spritesheets and wire expression changes to game events.

**Pixel art** is the fallback for personality characters not yet in the library and the default for non-personality entities (enemies, items, game objects).

**Real logos** are preferred for brand identity. When a game features OpenAI, Anthropic, Google, etc., download their logo and use it.

**Meme images** from the source tweet (`image_url` in thread.json) should be downloaded and incorporated when they enhance visual identity.

All tiers share the same fallback pattern: if an external asset fails to load, fall back to pixel art.

South Park Character System

See `character-pipeline.md` for the full South Park character system: character library structure, expression constants, expression wiring pattern, bobblehead body pattern, and building new characters (4-tier fallback from full expression build to generative pixel art).

Pixel Art Rendering System

See `pixel-renderer.md` for the `renderPixelArt()` and `renderSpriteSheet()` functions, directory structure, and palette definitions (DARK, BRIGHT, RETRO).

Integration Pattern

See `integration-patterns.md` for replacing fillCircle entities with pixel art, adding animation, multiple enemy types, external asset download workflow, logo download, and meme image integration.

Sprite Design Rules

When creating pixel art sprites, follow these rules:

1. Silhouette First

Every sprite must be recognizable from its outline alone. At 16x16, details are invisible — shape is everything:

• **Bat**: Wide horizontal wings, tiny body
• **Zombie**: Hunched, arms extended forward
• **Skeleton**: Thin, angular, visible gaps between bones
• **Ghost**: Wispy bottom edge, floaty posture
• **Warrior**: Square shoulders, weapon at side

**Readability at game scale**: Test your sprite at the actual rendered size (grid * scale). A 12x14 sprite at 3x scale is only 36x42 pixels on screen — fine detail is lost. For items and collectibles below 16x16 grid, use bold geometric silhouettes (diamond, star, circle) rather than trying to draw realistic objects. Use a **2px outline** (palette index 1) on all edges for small sprites to ensure they pop against any background. Hostile entities (skulls, bombs) should have a fundamentally different silhouette from collectibles (gems, coins) — size, shape, or aspect ratio should differ so players can distinguish them instantly even in peripheral vision.

2. Two-Tone Minimum

Every sprite needs at least:

• **Outline color** (palette index 1) — darkest, defines the shape
• **Fill color** — the character's primary color
• **Highlight** — a lighter spot for dimensionality (usually top-left)

3. Eyes Tell the Story

At 16x16, eyes are often just 1-2 pixels. Make them high-contrast:

• Red eyes (index 3) = hostile enemy

-