Communitygithub.com

Waipjy/ClaudeGame

Art direction guide for Pour Decisions. Defines the material palette, falling sand particle coloring & glow, URP post-processing (bloom, LUT, CRT), Pixel Perfect Camera, Balatro-style scoring UI & juice, 16–32px icons, Steam capsule art, and visual QA before commits. Read this whenever work involves colors, shaders, UI appearance, icons, or store art.

What is ClaudeGame?

This markdown file serves as the definitive art direction and visual style guide for the game “Pour Decisions.” It establishes strict rules and workflows for all visual elements—from the material color palette and pixel art fundamentals to post-processing effects and UI juice. The guide is designed to be read by AI agents (e.g., Claude Code) before any task involving color, shaders, UI appearance, icons, or store art, ensuring consistency and preventing ad-hoc decisions. It covers a limited palette system based on Resurrect 64, hue-shifting rules, luminance contrast hierarchy, and glow budgets for falling sand simulations. Platforms include Unity 6 with URP, targeting pixel-perfect rendering at resolutions like 320×180 upscaled to 1080p/1440p/4K with integer scaling. The guide also references auxiliary documents for detailed material parameters, post-processing recipes, UI animation timings, and Steam capsule specifications, all organized to support a coherent, playable visual identity without relying on generative AI or hand-drawn illustration.

Works with✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Waipjy/ClaudeGame/tree/HEAD/.claude/skills/art-direction
View original→Browse all skills

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Art Direction — Pour Decisions

The screen is about 80% simulated pixels. The art budget is spent only on: material palette, glow/post-processing, UI, icons, Steam capsule art. Hard rule: No generative AI images (triggers Steam disclosure); external assets only from the whitelist (docs/research/03_assets_legal.md), and registered in docs/art/ASSET_LICENSES.md. Our strengths: shaders, procedural rendering, color math. Weakness: hand-drawn illustration → all decisions lean towards "compute it with code."

Extended references (read only when details are needed):

  • references/material-palette.md — Ramps, HEX, noise, and glow parameters for 14 materials (starting values)
  • references/urp-postfx.md — URP Volume recipes, CRT shader specs, Pixel Perfect settings
  • references/ui-juice.md — Balatro UI breakdown, scoring animation timings, easing values
  • references/steam-capsule.md — Capsule art specs, Valve rules, non-illustrator approach

1. Color Theory (Decide in This Order)

1.1 Value (Luminance) Before Hue

  • Design the scene in grayscale first: convert to grayscale (luma = 0.299R + 0.587G + 0.114B, or OKLab L), ensure background, materials, and UI have distinct layers. If grayscale doesn't separate them, changing hue won't help.
  • This game's luminance layers (target L, OKLab 0–1):
    LayerL RangeContent
    Background / Beaker interior0.12–0.22Dark, low saturation, cool purple
    Inert materials (stone, sand, gunpowder, seeds)0.30–0.65Mid luminance, mid-low saturation
    Fluids (water, oil, acid)0.35–0.75Mid luminance, distinguished by motion & transparency
    Reactions/glow (fire, lava, spark, score particles)0.75–1.0 + HDRBrightest and most saturated on screen
    UI numbers/buttons0.85–1.0On separate panels, differentiated by panel background
  • Rule: The focal point must be the brightest, most saturated element. Focus = reaction location + score numbers. Nothing else should be brighter.

1.2 Hue Shifting

  • A ramp (dark → light) does not just adjust luminance: light areas shift towards warm (yellow), dark areas shift towards cold (blue/purple). Shift 10–20° per step, with a 20° upper limit (Slynyrd Pixelblog 1).
  • Do not use "add black" for shadows or "add white" for highlights → results in muddy, gray tones (pillow/muddy).
  • Saturation curve: highest in the midtones, falling off at both ends but never reaching 0 or 100%; dark colors can be more saturated than light colors. Avoid simultaneous high saturation + high brightness (harsh), reserve that spot for emissive materials.

1.3 Saturation Hierarchy

  • Saturation is the second attention magnet. Three tiers:
    1. High: Emissive materials, score effects, Mult numbers.
    2. Medium: Main colors of normal materials, interactive UI.
    3. Low: Background, beaker glass, panels, non-interactive text.
  • Background saturation ≤ 25% (HSV S). The overall screen should be "mostly low saturation, with a few high saturation points" to create focus.

1.4 Limited Palette

  • Use a single main palette; all materials, UI, and icons draw colors from it. Advantage: consistency is automatic, AI agents won't pick arbitrary colors.
  • Starting point: Resurrect 64 (lospec.com/palette-list/resurrect-64), 64 colors, ramps already hue-shifted, dark tones lean purple, suitable for dark backgrounds + glow. Alternatives: Endesga 32, Apollo (46 colors), AAP-64. Palette values themselves are not copyrightable; Lospec page attribution is optional but low risk.
  • Custom creation process (if needed):
    1. Pick a vivid midtone (S, B most important, H arbitrary).
    2. Expand 5–9 steps to both sides: B from dark to light (step size decreases near 100), S peaks at midtones, H +10~20° per step (shift warm towards light).
    3. Rotate the entire ramp by 45° H to create other color families.
    4. Duplicate the midtones, desaturate → neutral gray ramp (for UI/background).
    5. All color values in Game/Assets/Art/Palette/palette.png (1px per color) + C# PaletteSO, code references only indices, never hardcoded HEX.
  • Allowed exceptions: HDR glow values (>1.0) must be generated by multiplying palette color with intensity, not creating new colors.

2. Readability Rules

  1. Grayscale Test: Every color change: screenshot, convert to grayscale (QA checklist item #1).
  2. Adjacent materials must differ significantly in value or hue: ΔL (OKLab) ≥ 0.08 or Δhue ≥ 40°. Special handling for easily confused pairs:
    • fire vs lava vs sand (all warm) → fire: brightest and moving, lava: dark red base with bright veins and slow, sand: non-emissive and mid luminance.
    • acid vs plant (both green) → acid: yellow-green + slight glow + bubbles, plant: deep blue-green, non-emissive.
    • steam vs smoke → steam: white, cool, rises fast; smoke: gray-purple, darker, spreads slowly.
  3. Color blindness: Cannot rely solely on red/green discrimination. Each material must have an additional non-color characteristic (motion, noise pattern, glow, transparency). Use Coblis or a shader to simulate deuteranopia.
  4. UI separated from game screen: Simulation area contains only material pixels; UI sits on panels outside the beaker, using neutral low-saturation colors + 1px border. UI never uses material colors as background (to avoid "Is this sand?"). Score numbers can float into the simulation area, but must have outline/shadow and exit within 0.6 seconds.
  5. Single focal point: Only one set of elements should "compete for attention" at a time. During mass reactions, reduce glow of secondary particles (see §4 glow budget).
  6. Silhouette: Beaker, buttons, icons must be recognizable in pure black silhouette.

3. Pixel Art Basics

  • Fixed pixel scale: 1 simulation cell = 1 game pixel. UI pixel assets use the same scale (recommended sim resolution 320×180 or 384×216, integer scaled to 1080p/1440p/4K). Mixing different scales is forbidden.
  • No mixels: No pixel asset may be scaled non-integer or rotated (rotation produces uneven pixels). Rotatable UI (card wobble) should use a high-resolution UI layer, or rotate in a low-resolution render texture then integer scale.
  • Ramp: 3–5 colors per material (see references/material-palette.md). More than 5 colors are indistinguishable on 1px particles.
  • Dithering correct usage: Only for (a) large area gradients (background, beaker glass reflections), (b) transparency illusion (smoke, steam using checkerboard/Bayer 4×4 alpha). Do not dither on small objects, icons, or text; do not use world-space dither on moving particles (it flickers); dither pattern must be locked to screen space or cell coordinates.
  • Manual anti-aliasing: Only on diagonal/curved lines of UI icons and logos, place 1px of intermediate color between line and background. Do not AA outer contours against transparent backgrounds (dirty edges appear on different backgrounds).
  • Banding: Avoid parallel, equal-width color bands following a contour (looks like topographic lines).
  • Pillow shading forbidden: Light source fixed top-left; shadows are not "bright center, dark edges".
  • Fonts: Pixel fonts only from whitelist (Cubic 11, Fusion Pixel Font, Kenney Fonts); display at integer multiples of native pixel size; TMP uses Point-sampled bitmap or high sampling SDF.

4. Coloring Falling Sand Particles

Observations from reference works (Noita, The Powder Toy, Sandspiel, Sandustry; some are inferred, marked "unverified"):

  1. Per-particle color noise: Store a random byte at particle creation (Sandspiel's ra), use it during rendering to select a color or adjust brightness within the material's ramp → sand, stone have granularity. Noise fixed at creation, particle carries its color (do not re-randomize each frame, it flickers).
  2. Solids use world-coordinate texture: Noita materials can specify texture_file, solids sample texture based on world position; when turning into falling particles, retain the sampled color (inferred from wiki attributes, details unverified). Our stone/glass/ice can use cell-coordinate hash to sample ramp for stable texture.
  3. Fluids rely on motion, not noise: water/oil noise amplitude small (±3% L), plus (a) a slightly brighter highlight on the surface cell, (b) subtle shimmer based on velocity/time.
  4. Emissive materials: Noita has gfx_glow (0–255) and gfx_glow_color. Our approach: each cell has an emission value, rendering outputs HDR color = palette color × (1 + emission × k), fed to URP Bloom. fire, lava, spark, acid (weak), glowing glass emit.
  5. Temperature color: The Powder Toy has a heat display mode; we adopt the spirit: material temperature shifts along blackbody curve (dark red → orange → yellow → white) toward bright end, cools back to original ramp.
  6. Reaction flash: The cell where a reaction occurs gets maximum emission for that frame, decays over 2–4 frames → player "sees" the reaction. This is the most important readability feedback.
  7. Glow budget: If simultaneously glowing cells > N (starting 2,000), proportionally reduce each cell's emission to maintain overall brightness stability, avoid screen washout.

Implementation notes: sim data (material id, random byte, temperature, emission) packed into RGBA8 texture and uploaded; fragment shader queries a palette LUT (256×1 or materials×ramp small texture) to determine color. CPU does not calculate color.

5. Post-Processing (Unity 6 URP) Key Points

Full recipe in references/urp-postfx.md. Core:

  • Camera HDR enabled; Bloom Threshold 1.0–1.1 (only HDR>1 emissive materials bloom, normal materials don't), Intensity 0.6–1.0 starting point, Scatter 0.6–0.75, High Quality Filtering on (reduces flickering).
  • Tonemapping: Neutral (ACES changes hue, crushes palette). Or None + manual control.
  • Color grading LUT: only subtle unification (cinematic "hearth glow" look), does not alter palette value structure; Color Lookup contribution ≤ 0.5.
  • CRT/scanline disabled by default, toggle & intensity in settings; Steam screenshots/trailers primarily "off", at most 1 screenshot with it on.
  • Pixel Perfect Camera (built-in URP, not the old 2D Pixel Perfect package): Grid Snapping = Upscale Render Texture; Bloom applied at the upscaled resolution to avoid blocky halos.

6. UI Style (Balatro-style score-attack)

Full timing in references/ui-juice.md. Mandatory:

  • Color is the scoring language: Chips = blue, Mult = red, Money = gold, ×Mult = red background white text. Fixed throughout the game, never repurposed.
  • Itemized settlement: Reactions pop one by one (+chips / +mult), each with number pop (scale 1.0→1.3→1.0, overshoot easing), pitch ascending.
  • Shake scales with magnitude: Larger scores = larger amplitude, longer duration; max 8px / 1°. Provide "reduce screen shake" option (accessibility).
  • Numbers always readable: Thick outline (2px dark) + shadow; use scientific notation only after thousands separator.
  • Juice must not obscure information: Particles and flashes must not cover chips×mult and target score.

7. Icons (16–32px)

  • Create 16px version first, then upscale to 32px and add details (do not shrink 32px to 16px).
  • One icon = one concept, one silhouette; 1px dark outline (palette's darkest color) ensures it works on any background.
  • Each icon max 4–5 colors (outline, dark, mid, light, accent). Light source always top-left.
  • Vial (material bottle) icons: uniform bottle shape, change only liquid color and one small symbol (flame, droplet, skull…) → players identify by color + symbol (colorblind friendly).
  • Catalyst relics: shape based on rarity (circle / hexagon / star frame), frame color per rarity (gray, blue, purple, gold).
  • Procedural generation: icons can be drawn using C# or Python with "shape + palette index" to output PNG, reproducible, batch-editable.
  • Testing: view at actual UI background, 100% scale; at 50% scale, still distinguishable pairwise.

8. Steam Capsule Art

Full details in references/steam-capsule.md. Key points:

  • Specs: Header 920×430, Small 462×174, Main 1232×706, Vertical 748×896, Library 600×900, Hero 3840×1240 (no text), Logo transparent PNG.
  • Valve rules: Capsule can only contain game visuals/art and game name logo (and official subtitle); no ratings, awards, discount text, or other text.
  • Our approach (non-illustrator friendly): Font-driven large logo + high-resolution simulation render (explosive reaction moment) + one clear focal point. Logo itself is falling sand: use simulation to "pour" letters or compose letters from different materials.
  • Start with Small capsule (120×45 preview still must show logo clearly), then scale up.

9. Workflow Rules

  1. New color → add to palette file first, then reference; PR/commit description lists new indices.
  2. Any external asset (font, Kenney UI) → log into docs/art/ASSET_LICENSES.md (filename, URL, author, license, date).
  3. All procedural art (icons, logo, capsule art) keep generation scripts and parameters in Game/Tools/ArtGen/ or tools/, rerunnable.
  4. Uncertain parameters marked "starting value", fill in references after prototype playtest.

10. Pre-Commit Visual QA Checklist

  • Grayscale screenshot: background / materials / glow / UI four layers have distinct luminance
  • Focal point (reaction site, score numbers) is the brightest and most saturated element on screen
  • New colors all from palette (no hardcoded HEX)
  • Adjacent easily confused materials (fire/lava/sand, acid/plant, steam/smoke) distinguishable at 100% and 50% scale
  • Under colorblind simulation (deuteranopia, protanopia) materials and Chips/Mult still recognizable
  • No mixels: pixel assets all integer scaled, not rotated
  • Particle color noise does not flicker during movement
  • Bloom: normal materials do not bleed; 500+ simultaneous reactions don't wash out screen (glow budget active)
  • UI text has outline, remains readable above brightest explosions
  • Screen shake ≤ 8px, "reduce shake" option off → no shake
  • CRT filter off by default, toggle works
  • Icons at native 16px size are distinguishable pairwise
  • 1080p, 1440p, Steam Deck 1280×800 all have integer scaling or correct letterbox
  • No generative AI output; new assets have registered licenses
  • Screenshots saved to docs/art/qa/<date>_<feature>.png for review

Sources

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Waipjy/ClaudeGame

設計或修改 Pour Decisions 的規則、材料（vial）、催化劑（catalyst）、計分公式、目標分數曲線、商店經濟、難度階梯、教學，或要跑平衡模擬、審查新卡/遺物時使用。

Related Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community