Game Visual Hierarchy

Core Idea

The attention a player can allocate to a frame in any given moment is limited. Any "noticeability"—brighter, darker, more saturated, denser, larger, in motion—draws from the same budget. Hierarchy is how you allocate that budget: the more gameplay-critical and immediately reactive the information, the more exclusive and powerful the means of standing out; everything else yields.

The key action is constraining the lower layers, not boosting the upper ones. If you only make the important things brighter, other assets will also get brighter, and soon everything is shouting. An effective approach is to carve a narrow range for the bottom canvas, leaving room in the direction needed by the upper layers.

The method is distilled from Riot's 2014 blog post "Defining the Rift's Visual Style." What comes from the original, what is the skill's own inference, and measured data are in references/rift-case-study.md; other sources are in references/sources.md.

0. Find Your Project's Own Specifications First

First, find these things in your project:

Art direction and color specifications, palette files, QA screenshot records, and issues already stated in review pages.
Device and export tool limitations, such as the frame rate cap of an LED display or how brightness is driven.
Decision records: what has been done and what has been rejected.

Once found, adopt its terminology and color space, and use its numbers as acceptance criteria. Distinguish assumptions in code comments from verified facts. If the specification conflicts with the principles here, point it out—do not rewrite it arbitrarily.

1. Start from the Player's Required Judgments

First ask: what must the player read at this moment? Where am I; where can I go; who is enemy, who is ally; what is about to hit me; what can I do now; what just happened. And what they read must be true: something that looks traversable, harmful, or area-of-effect must actually be so in gameplay.

Prioritize by two factors: Urgency—how costly is it to miss, and how fast must the player react? It matters if it lets the player dodge, interrupt, or reposition; effects the player cannot counter should not be styled as warnings. Persistence—is it constant or transient? Usually the top priority is a "transient and lethal" signal.
Focal point: mark where the player is looking at that moment (character, crosshair, cursor). Signals near the focal point can rely on color and shape; urgent signals far from it rely on motion, area, or global changes at the screen edge.
Phases: explore vs. combat; browse/select/settle—rank each phase separately; when entering a phase, actively lower layers unrelated to it.
Layer by function, not by asset: a cliff edge or a pickup is gameplay information and belongs to the upper edge of the environment layer; decorative particles belong to the environment layer even if technically "effects."
Draw order is not prominence priority: tower defense projectiles are drawn above enemies, but they are numerous and carry little individual information—they must be small and short.

For per-type layer stack starting points, see references/layer-stacks.md.

2. Channels of Noticeability

Channel	Characteristics
Light-Dark Contrast	Strongest and fastest; works even in grayscale; the primary choice for layering.
Saturation	Second strongest. A small area of high saturation will catch the eye.
Hue and Warm-Cool	Very strong when contrasting with the scene's dominant color family, e.g., cool colors in a lava scene; unreliable within the same color family or red-vs-green. Also used for semantic meaning.
Detail Density	High-frequency textures are noise that dilutes attention.
Shape, Area, Silhouette	Shape language distinguishes signal types; silhouette determines recognizability from afar.
Motion and Appearance	Extremely effective for peripheral vision; sudden appearance beats gradual fade-in. When the highest-priority signal uses motion, other looping animations should pause or downgrade.
Position and Framing	Screen edges, grounding plates, outlines, bottom rings. Primarily used for persistent UI.
Full-Screen Tint and Total Brightness	Read first when glancing from a distance; suitable for conveying global states.

Brightness metric: whether it separates in grayscale depends on perceptual lightness (L*). HSB's V conflates "bright" and "saturated": pure blue has V=100 but L* is only 32. When specifying brightness with numbers, specify which metric.

3. Allocation Rules

Canvas is narrowest, and leave room in the direction the upper layers need. By default, leave room at both ends. For dark games and LED displays, the canvas can hug the dark end; then upper layers can only expand outward toward light and saturation, supplemented by outlines, silhouettes, and motion.
Upper layers contain the lower layers, then expand outward. Upper layers can use midtones from the canvas and be seen by what they add: brighter highlights, deeper silhouettes, more saturated accents. Within a layer, prioritize: the expanded part is spent on gameplay-informative small parts (facing, weapon, weak point, wind-up limb); the rest becomes low-detail resting area.
The strongest channel is reserved for the top-priority signals from section 1, as an exclusive slot. An exclusive slot is carved out from all other layers and belongs only to its owner. One slot corresponds to one meaning so the player can learn it; anything else entering it is a false alarm. It does not have to be "brightest"—it can be a specific hue, shape, or motion, or assigned per phase.
Noticeability × Area × Duration × Count = One Budget. The budget constrains what competes with the primary signal; the primary signal itself must first be visible at viewing distance.
- Short durations are for hit-flashes and result feedback. Warnings are the opposite: they appear before the hit, leave enough reaction time, and escalate as the threat approaches.
- Count can overwhelm the frame: hundreds of projectiles or floating texts on screen must be throttled by count. Large-area indicators should lower fill density, making only edges prominent, and take the union when overlapping.
- Persistent UI first and foremost must not block gameplay (around the player character, forward direction, next interaction point); then be narrow, small, and edge-aligned. World-space UI like health bars and damage numbers count toward the budget of the layer they annotate.
- Flashing safety overrides hierarchy: "short" does not reduce photosensitivity risk. Large-area flashes should not exceed 3 per second; avoid saturated red flashes.
Compare locally. Look at the element against the actual, worst background it contacts. For elements that will pass through both dark and bright backgrounds, use a double outline (one dark, one light).
Order of fixing problems: lower first, then switch channels, then boost last. Start by pulling back the overreaching lower layer; then consider giving the signal a channel the lower layer hasn't occupied (hue, shape, appearance mode, position); only finally strengthen the upper layer. After lowering, retest: elements that were separated by "darker than background" might now stick to it.
Beware of upgrade inflation. Max-level or high rarity should be expressed through silhouette, parts, and animation, staying within the same range.

4. Environment: Step Back, and Guide

Stepping back relies on simplification, not blurring: use large shapes and light-dark masses instead of fine high-contrast textures. Blurring the whole thing also lowers the metric, but materials become unrecognizable. Common changes: reduce saturation, lower ground texture contrast, reduce environmental light sources—often without touching the character first.
Guiding: traversable areas are flatter, quieter, and maintain a stable lightness difference from boundaries; boundaries are darker, denser. It is a quiet hint, not an arrow.
Within the environment, also layer: terrain related to gameplay sits at the upper edge of the range; pure decoration sits in the middle. Environmental light sources compete with exclusive slots—they must be reduced, dimmed, or given gameplay meaning.

5. Unity and Technical Artifacts

All assets return to the same vision, with scale proportional to the character. The wider the character style range, the more the environment should stay in the middle; when evaluating a new asset, place it next to the two extremes of the roster.
Stylistic identity can come from a deliberate set of shape contrasts (soft vs. sharp), then controlling the ratio of realistic reference to fantasy elements.
Hard polygon edges, seams, tiling repeats, flickering, overly realistic gritty textures attract attention without conveying information—hide them or turn them into a deliberate style. Deliberately retained structures like grids, pixel blocks, and outlines are not artifacts.

6. Project-Specific Adjustments

Dark / Horror: "Bright" is a scarce channel. Multiple signals will become bright spots in the black—distinguish them by shape, height, and motion; do not place critical information solely in the darkest tier.
Bright Cartoon Style: When both ends are occupied by style, let the canvas retreat to midtones, or use a dark outline to separate characters.
3D / Realistic / Dynamic Lighting: Final lightness is determined by material, lighting, and camera together. Estimate lighting before setting ranges, then measure on the post-processed frame. See references/3d-lighting.md.
Pixel Art, Limited Palette, LED Matrix, Small Screen: See references/limited-palette.md.
Color Vision Deficiency: Hierarchy relies mainly on lightness; semantic colors should be paired with shapes and icons. When using a hue-based exclusive slot, check simulated views for protanopia and deuteranopia.

7. Inspection Methods

Reason first, then measure. First, derive a judgment using the above rules and common sense of the genre: how does light attenuate, what are the device limits, when does the player make judgments. Measurement should only answer specific questions; do not let mosaics and number-crunching replace reasoning.

Verify evidence first: is the screenshot from an older version, are there debug overlays, were lights and post-processing active at capture time. See references/evidence-and-measurement.md.
Take the worst case: the most crowded moment, the moment the player makes a critical decision. For transient signals, look at the start-up frame, not the fully lit peak. For state changes, compare two frames from the same camera angle.
Three quick tests: does the hierarchy remain in grayscale; after blurring, where does the eye land first; if you paint a layer solid, is the pose and facing still recognizable.
Check critical signals per channel: compare the highest-priority signal against its actual adjacent competitor, one channel at a time from section 2.
Measurement: The scripts/sv_profile.py in this skill directory reports per-layer area, saturation and lightness ranges, perceptual lightness, detail density, exclusive slot ownership, and local contrast. It supports the project's color space, two-frame comparison, and multi-frame GIF. scripts/palette_check.py checks layered palettes before drawing. See -h for parameters; reading methods in the reference file above. Output goes to a temporary directory, not into the project.
```
python <skill-dir>/scripts/sv_profile.py shot.png -o <temp-dir> -r "!environment:0,0,1,1" -r "player:0.42,0.40,0.50,0.55" -r "hud:0,0.88,1,1"
```
Illustrative frames are control experiments only: when no screenshot is available, you can compose frames with color blocks, but change only one variable at a time, and lighting must roughly match reality. Numbers measured from self-composed frames cannot be presented as "current state" nor used as proof of a proposed solution's compliance.
Numbers are merely evidence: the conclusion must return to "can the player read what they need to read." When acceptance is required, write player re-test metrics.

8. Output

The review is read-only by default: do not modify assets, code, or project documentation; only write suggestions. First answer the user's question directly; say the same judgment only once.

Review screenshots: start with a one-sentence conclusion. Then order findings by gameplay impact: first "where am I, where are enemies, what is about to hit me" and UI obstruction; then environment competing with characters for attention; finally style and technical artifacts. For each finding, write location, phenomenon, violated principle, and minimal change.
Before/after comparison: answer item by item: did "what the player must read" get better or worse? Keep the judgment about this pair of screenshots separate from what to do for the current version.
Diagnosis with only text description: give the most likely cause and an investigation order, provide checks the user can run themselves and concrete steps inside the engine, and list possible causes outside the frame (duration, hitbox, camera, sound).
Create a specification: first complete the ranking from section 1, then write the range for each layer, exclusive slot assignment, constraints on area/duration/count, with compliant and non-compliant examples. The specification must be directly actionable:
- Cover every element type the user named.
- Give starting values in the executor's units (grid cells, pixels, seconds, engine field names) and mark "to be verified"; do not refuse to give numbers just because there's no screenshot.
- Write the render order and scheduling rules: who overlaps whom, stacking limits, when to clear.
- Finally list a few red lines and the implementation order.
If art exists but no screenshot is provided, ask the user for screenshots for calibration.

Common rules:

When evidence is insufficient, reduce conclusions; don't just add a footnote. Do not extrapolate numbers from things not in the screenshot.
For elements whose purpose is unclear, first look them up in the project; if still unclear, give conclusions for both possibilities and ask the user.
When there are multiple possible causes, first give a diagnostic that can be quickly verified in one step, then give fixes per case.
Before proposing a fix, check what the project has already tried or rejected. Use only the project specification or its own compliant frames as the baseline; do not use numbers from reference cases as standards.
Do not arbitrarily change the project's established art style; when suggesting changes, write the benefit and cost.

game-visual-hierarchy