Color for Developers: Value First, Hue Last
Color feels unlearnable because people learn it as hue. Almost every practical failure is a value failure, and value can be measured in ten seconds.
Your game looks muddy and you cannot say why. Or the character gets lost in half the rooms. You try a different blue and nothing improves, because the problem was never the blue.
Color is the property developers feel least qualified to judge, so it gets handed to whoever is drawing and comes back as problems that look unfixable from the code side. That is a misfiling. Almost every practical color failure in a game is a value failure, and value is measurable in ten seconds with software already on your machine.
The short version. Value is lightness, it decides readability, and you check it by desaturating a screenshot. Saturation is intensity, it decides attention, and you set it by policy. Hue carries mood and is the only one that is really craft. Work in that order, reserve the top of the value and saturation ranges for the player and the interactive objects, and most color problems in a small game are gone before anyone argues about the blue.
Value, saturation, hue, in that order
Value is lightness, how light or dark a color is, ignoring what color it is. A fire engine red and a mid gray can sit at identical value. The eye resolves value faster and at lower contrast than hue, so value tells a player where things are before they have consciously read anything. Value decides readability, and readability decides whether the game can be played.
Saturation is intensity, how far a color sits from gray. It builds no structure, but it pulls: the eye goes to the most saturated thing in the frame, all else equal. Saturation decides attention.
Hue is the color name, blue, orange, teal. It carries mood and association, and it takes taste to get right.
Rank those by consequence and you get value, saturation, hue. Rank them by how easily a non-artist can check them and you get the same order: value is measurable, saturation is a policy, hue is an argument. Work down the list, because each thing you settle constrains what sits below it and the reverse never holds.
Invert the order and you get a specific set of failures, all described in words pointing at hue.
- "It looks muddy." Too many elements at the same middle value, so the frame reads as one substance.
- "It looks flat." The value range in use is narrow, so nothing recedes and nothing advances.
- "The character disappears here." Character and background share a value where the character stands.
None of those is fixable by changing a color in the sense a developer means it. Repaint them in nicer hues at the same values and the problem is identical.
The desaturation test is the cheapest diagnostic in game art
One check does more than every other color check combined.
- Screenshot the running game, in a real scene, with the HUD on.
- Scale it to the size a player sees, on the display they will use.
- Convert to grayscale. Any image editor, or your engine's own desaturation post-process.
- Look for two seconds, then stop looking.
Two seconds is the whole protocol: you are testing pre-attentive reading, not study. What to look for, in order:
- Does the player pop. The character should be the most findable thing in frame. If your eye lands on a wall panel first, the scene is telling the player the wrong story.
- Are the layers separable. Background, midground, gameplay objects and interface should occupy distinguishable value bands. If the image reads as one continuous field, your layers are not layered.
- Does anything unimportant read as brightest. A decorative light fixture at the top of the value range reads as significant for as long as it is on screen.
- Does the HUD hold. Interface that survives in color and dies in grayscale is carried by hue alone, and hue alone fails on cheap panels and for a share of your players.
Trust this over your own eye in color, because color is the thing fooling you. A screenshot that fails cannot be rescued with better hues. Moving a color around the wheel does not change how light it is, so a character with no value separation still has none in a prettier palette. Every fix is a value fix: darken the background band, lighten the character, or widen the gap.
Color is four decisions, not a mood board
Interface art becomes tractable once you treat it as four decisions made once. Color works the same way, and none of these require drawing.
1. A value range per layer. Name the layers your game has, usually background, midground, gameplay objects, effects and interface, and give each a band on a lightness scale from 0 for black to 100 for white. Overlap as little as you can stand.
2. A saturation policy. Decide which layers may be intense. One sentence does it: "rooms stay in the lower half of the saturation range, cast and interactables use the upper half."
3. A hue relationship. Not a list of colors, a relationship. Pick a small set the world uses, then state how everything else relates to it: the same hues at a different saturation, or a range the world never touches.
4. A reservation rule. What may be the brightest thing on screen, and what may be the most saturated. It gets its own section, because it returns more than the other three combined.
The reserved color: the top of the range belongs to the player
Here is the highest-leverage color rule in a small game. Take the top of your value range and the top of your saturation range, reserve both for one category of thing, and require everything else to live below. That category is almost always the player character, and just under it the objects a player can interact with.
The eye goes to the brightest and most saturated thing in a frame without being asked. If that is always the player, the player never searches for themselves. If it is sometimes a wall light and sometimes a background sign, the player scans the screen a few times a minute for the rest of the game and calls the result hard to read.
- It is a cap, not a target. Nothing is required to be bright. Things are forbidden from being brighter than the reserved band.
- It is checkable. Desaturate, find the brightest region, name it. Then name the most saturated region in color. Both answers should be the same short list.
- It survives new assets. Everything delivered later gets checked against one sentence.
Write the exceptions down rather than discovering them. A danger telegraph may break the ceiling for its duration, since that is when attention should leave the player. Permanent exceptions are the rule not being followed.
A palette is a constraint, not a decoration
Most teams treat the palette as an output: colors appear, someone collects them. Inverted, it is one of the cheapest production tools available, because a palette fixed early makes every later asset cheaper to judge.
The question about an incoming background stops being "do I like these colors" and becomes "is this from the set, and does it sit in its layer's band." The first has no answer and takes a week. The second takes a minute, and it is the same minute for asset one and asset two hundred.
- Make it small enough to memorize. If you cannot recite the set, it constrains nothing.
- Spread it across the value range on purpose. Eight colors at middle lightness are eight ways to make a muddy frame.
- Write it as hex values in your art bible, next to the layer bands, and allow tints and shades of the set but never new hues.
Constraining a palette after two hundred assets exist is a repaint. Constraining it before the first one is a paragraph. A generated collection does it structurally: when a cast, a room set and an interface are baked against one palette definition, as Makko does, the relationship holds across the whole set.
Two problems in the corpus that are really value problems
The UI palette relationship. The interface rule says to decide how the UI palette relates to the world palette, the two workable answers being UI outside the world's hue range or world hues at a different saturation band. Both exist to stop the interface colliding with what sits behind it, and hue alone does not achieve that: a health bar in a hue the world never uses still vanishes when its value matches the wall. Add a value clause, so the interface occupies a band the world is not allowed into and the hue rule sits on top. Then run the desaturation test with the HUD on, which also catches an icon that stops reading at shipping size.
Character against background. Separation in environment work has four levers: value, detail density, saturation and edge treatment. Value is strongest by a distance, and it belongs to the room rather than the character. Real production builds that into the files: in a measured hallway set, the top and bottom framing pieces are authored with the middle left empty, so the band where characters walk carries no competing art at all.
Separation is a property of a pair. The thing a character reads against is where the fix goes.
What you can judge and what needs a colorist
You can judge value structure, because grayscale makes it visible. You can judge readability, because it is a pass or fail question about finding the player. You can judge palette discipline, because it is set membership. You can judge the reservation rule, because it is one sentence and a screenshot. That is engineering, and it covers most of what makes a game look broken.
You cannot reliably judge hue harmony, whether a set of hues has a relationship rather than merely coexisting. You cannot judge mood, whether a room says abandoned rather than merely dim. You cannot judge temperature logic, whether the warm and cool areas agree about where light comes from. You cannot judge appeal.
That is what a colorist sells. The split is the same one the programmer's overview of game art draws between producing art and specifying it. Get the value structure right yourself. Spend on hue when there is money, on the scenes the player sees first and occupies longest.
The color contract, in one block
Copy this into your art bible and fill it in. It settles the arguments before they start.
# [GAME] - Color contract v0.1
## Value bands (lightness 0 = black, 100 = white)
background = [ ] to [ ]
midground / props = [ ] to [ ]
gameplay objects = [ ] to [ ]
player = [ ] to [ ]
interface = [ ] to [ ]
max overlap, adjacent bands = [ ]
## Saturation policy
environments = [ lower ] half
cast + interactables = [ upper ] half
effects = [ rule ]
## Hue relationship
world = [ 3 to 5 hues ]
UI = [ outside world range / world hues, other saturation ]
danger = [ hue reserved, used nowhere else ]
## Reservation rule
brightest on screen = [ player / interactable ]
most saturated = [ player / interactable ]
everything else caps below
exceptions = [ telegraph + duration ] [ cutscene ]
## Palette
[ n ] hex values, spread across the value range.
Tints and shades only, no new hue without a contract edit.
## Delivery check
Desaturate at play size, 2 seconds:
player pops / layers separate / HUD holds
The order of operations for setting color up front
Steps 1 to 5 happen before anyone produces a finished asset. All five are text.
- Name the layers. Take them from your render order, not the design document.
- Assign value bands. One range per layer, overlaps small, the player's band at the top with room around it.
- Write the reservation rule. One sentence for brightest, one for most saturated, plus any exception with a duration.
- Set the saturation policy. Which layers are muted, which may be loud.
- Pick hues last. Three to five for the world, a stated relationship for the interface, one reserved for danger.
- Build one vertical slice in the real engine. One room, one character, the real HUD. Not a mockup on a neutral artboard.
- Run the desaturation test on the slice. Fix in value, not in hue, until it passes in two seconds.
- Freeze the contract and produce against it. Every delivery gets the same two second check.
Step 5 being last is the argument of this article. Choosing hues inside a settled value structure is a pleasant afternoon. Choosing them first and repairing the structure afterward is a repaint.
Frequently asked questions
How do I desaturate a screenshot without an image editor?
Add a full-screen grayscale post-process and bind it to a debug key. Every 2D engine does it in a few lines of shader, and having it live in the build beats working from stills, since you can check value structure in motion.
Does this apply to pixel art with a fixed palette?
More than anywhere else, because a fixed palette is a value decision you have already made and probably never examined. Sort it by lightness and look at the ramp. Many popular sets are heavy in the middle and thin at the ends, so a game built from one drifts muddy with nobody making a mistake.
My game is meant to be dark. Does the value rule still hold?
Yes, compressed rather than abandoned. The bands get narrower and precision matters more. What kills dark games is a background creeping into the player's band because a room felt too gloomy in isolation. Judge every room with the character composited in.
How do I brief color to an artist or a generator?
Hand over the contract block, not adjectives. "Muted, mysterious, slightly melancholy" produces an argument. "Background in the lower third of the value range, cast and interactables in the upper third, environments in the lower half of saturation, brightest thing on screen is always the player" produces an asset you can check on arrival.