8 Color Mistakes That Make a Game Look Amateur

Amateur is not a verdict on talent. It is a short list of specific, repeatable defects, and in 2D games most are color defects unrelated to taste. A project can have competent assets, a clear theme and a real budget and still read as a student demo, because the same eight things go wrong and nobody names them.

This list is for a developer who can ship a game and cannot paint. Each entry gives the mistake, the symptom somebody would notice without knowing the cause, why it happens, and a fix you can check without drawing. Disclosure: this is the blog of Makko, an AI-powered 2D game art studio. It names no tools and quotes no prices, and it was written in September 2026.

One idea runs through all eight. Nearly every color mistake is a value problem wearing a hue costume. Value is lightness, where a color sits between black and white once the color is thrown away, and your image editor reports it as a number. Hue is taste. So every diagnosis below opens the same way: take the color out and look again.

The short version. Desaturate five real screenshots before you argue about a single color. If the scene turns to mush in grayscale, you have a value problem and no hue change will touch it. Assign every layer a lightness band before picking colors, keep saturation off anything that is not a signal, and ban signal colors from decoration. That grayscale pass catches six of the eight below; counting catches the other two.

How these eight were picked

Plenty of color advice is true and useless here, because applying it needs a trained eye. These eight cleared four tests.

• Diagnosable from a still. No build, no playtest, no meeting. A screenshot and five minutes.
• Checkable by someone who cannot paint. An eyedropper, a grayscale toggle, counting. Every fix has a pass condition with a number in it.
• Reported in disguise. Nobody files a value-collision bug. They say the game is busy, or that they missed the door.
• Expensive if caught late. Each touches every asset made after it, so month six means a repaint, not an edit.

They run in the order you must catch them. The first causes several of the rest.

1. Picking hues before a value structure exists

Symptom. The team keeps re-picking the palette. Each scheme looks correct as a row of swatches and wrong in the scene. Screenshots read flat whichever set is loaded, and the conversation loops with nobody able to say what is failing.

Why it happens. Hue is the visible, discussable part of color. Value stays invisible until you remove the color, so it never gets an agenda item, and no swatch tool asks for lightness ranges.

The fix. Before any asset is final, write a lightness band for each layer in render order on a 0 to 100 scale: far background, midground, play surfaces, props, player, enemies, interface. Forbid adjacent bands from fully overlapping and give the player the top. Then pick hues inside those ranges, where hue becomes a free choice. The band table, the overlap rule and a contract block for your art bible are in the companion piece on value structure. Bands are twenty minutes of typing and they end the loop.

2. Every layer of the scene living in one value band

Symptom. The scene reads as a single substance. Testers call it busy, or say they lose the character in fights, and neither points at a cause. In grayscale the whole image sits in the middle third of the range and you cannot say where one object stops and the next starts.

Why it happens. Assets get authored one at a time against a neutral canvas, where each looks best at a comfortable middle lightness. Forty individually correct assets make a scene with no structure, because nobody saw them together until it was assembled.

The fix. Eyedropper the pairs that touch, not the image as a whole. Sample the wall behind your character where the character is hardest to see, then the character's largest flat area, torso or coat, not a highlight. Read the L in HSL for each and subtract. Under about 10 points on 0 to 100 is the defect. The repair is usually to push the background band down 15 points rather than brighten the character, since a brighter character is a glowing figure in the same soup.

3. The interface sitting brighter than the player character

Symptom. Desaturate a screenshot with the HUD on and the brightest region in the frame is a health bar fill, a button face, or a notification badge. Players call the HUD intrusive, or lose track of themselves in combat.

Why it happens. Interface art gets built in its own file against a neutral canvas and judged alone, where white is the default answer for legibility. Nothing in that workflow compares the HUD to the character under it.

The fix. Cap the interface band below the player's band and build the HUD's internal hierarchy with value steps inside that cap rather than by reaching for white. The pass condition is one sentence: desaturate with the HUD on, and the brightest thing in frame is the player. An element that must be brightest to stay readable has a contrast problem against its own backing panel, and that is a fix inside the HUD.

4. Full saturation everywhere, so nothing reads as important

Symptom. The screen is loud and nothing on it is urgent. Players miss pickups sitting in plain sight. Single frames look vivid as thumbnails, and twenty minutes of play tires people out, reported as the game being hard on the eyes.

Why it happens. Saturation is what makes a single asset look finished, so everything arrives at full chroma. Nobody authored the scene as a scene, so intensity accumulates instead of being spent.

The fix. Treat saturation as a budget with a ceiling for environment art, the same way value gets bands. Sample the S in HSL across a dozen environment tiles, then across your player, pickups and telegraphs. If the median environment saturation sits within roughly 15 points of your signals, nothing has headroom to stand out, and the repair is to pull the world down, not push the signals up.

5. A signal color used as decoration until it stops signaling

Symptom. Players walk into hazards they clearly looked at. A tester says they thought the red panel was a poster. The code worked in the first area and stopped around the third, and no single change broke it.

Why it happens. It accumulates. Warning stripes in dressing, a red hit spark, a red damage vignette, a red close button, an enemy whose whole body is the hazard hue. Each is defensible alone. Together they teach the player, correctly, that red here means nothing.

The fix. Counting, not judgment. Open your busiest screenshot and count distinct objects carrying the hazard hue. More than three and the code is diluting. Then write the reservation as a ban: signal hues appear on signals and nothing else, and decoration uses tints and shades of the world ramps. A red object the fiction demands goes darker and desaturated, outside the signal's band. The companion piece on color as a gameplay signal carries the assignment block.

6. Signals that carry hue and nothing else

Symptom. A slice of your players never see a mechanic at all. One fight spikes in difficulty for reasons the metrics cannot explain. The cave level draws complaints that the game got unfair, and the screenshot looks fine.

Why it happens. Hue is the channel the designer notices, on a good monitor, on a still, already knowing where everything is. It is also the first thing a real scene takes away: it collapses in low light, degrades under motion and clutter, and weakens as objects shrink. Then there is the share of your audience, skewed heavily male, who permanently see a narrower hue space.

The fix. Every meaning carries hue plus at least one of shape, motion, a value step or an outline. The check is the grayscale pass again: desaturate, and any signal that disappears rode on hue alone. A one or two pixel outline in a contrasting value is the retrofit when something breaks two weeks from ship. Separating at-risk pairs by value does double duty, so red and green never sit at the same lightness.

7. A palette that grew one asset at a time

Symptom. The set does not look like one game. Assets from month one and month six sit beside each other and disagree. Nobody can answer which blue, because there are eleven and each arrived with an asset.

Why it happens. Nobody decided the palette, so each asset decided its own. Art from different sources, sessions or days lands on colors that are close enough alone and wrong against the set.

The fix. Count the unique colors in your shipped art. For flat or lightly shaded 2D work it should land in the dozens, as ramps running dark to light. A count in the thousands means no palette exists, found without an opinion in sight. Write it down as named entries with hex values and check deliveries against it; sizing a limited palette is a separate procedure. Sourcing art as sets removes most of this class at authoring time, and Makko generates collections against one palette definition, so a cast, a room set and an interface arrive already agreeing.

8. Every room in the game lit at the same temperature

Symptom. Players cannot remember which area they were in and describe the game as smaller than it is. Put one screenshot per area side by side at thumbnail size and they are hard to tell apart.

Why it happens. One lighting setup gets built early, works, and never gets revisited, because it sits in code rather than in any asset. Area variety then gets chased through props and tilesets, slower and weaker than changing the light.

The fix. Give each area a key light hue and an ambient shadow hue, written down and measurably different between areas. Hold the environment value ceiling identical everywhere, so the bright end keeps meaning the same thing and signals survive an area transition. The check is a contact sheet, one thumbnail per area: tellable apart in color, sharing a ceiling in grayscale. Different temperature, same structure.

The eight in one table

A triage pass you can run this afternoon

Run it in order, cheapest and most common first. A broader map of where color sits in the art pipeline is in the developer's overview of game color.

# Color defect triage - 45 minutes, no drawing

1. CAPTURE
   5 frames: busiest room, darkest room, most HUD on screen,
   a combat moment, first screen a new player sees.
   Real resolution, HUD on, character composited in.

2. GRAYSCALE PASS            catches 2, 3, 6
   [ ] eye lands on the player, not the HUD or a corner
   [ ] player silhouette traceable on every background
   [ ] every signal still findable with color gone

3. EYEDROPPER THE PAIRS      confirms 2   (L in HSL, 0-100)
   player vs wall behind    >= 15
   player vs floor          >= 12
   interactable vs surface  >= 12
   interface vs its backing >= 20

4. SATURATION                catches 4
   Median S of environment vs S of player and signals.
   Gap under 15 = no headroom. Pull the world down.

5. COUNT                     catches 5 and 7
   Hazard-hue objects in the busiest frame:  3 or fewer
   Unique colors in the shipped set:  dozens, not thousands

6. CONTACT SHEET             catches 8
   One thumbnail per area, color and grayscale.
   Tellable apart in color, same ceiling in grayscale.

7. ONLY NOW                  mistake 1
   If steps 2 to 6 pass and it still looks wrong, the problem is
   not on this list. That is when you hire a painter.

Frequently asked questions

Which of the eight should I fix first?

Whichever the grayscale pass finds, and in practice that is number 2 or number 3. Both are layer-wide rather than per-asset, so both often come out with a tint or multiply pass at runtime instead of reauthoring.

Do I need an image editor to desaturate screenshots?

No. A saturation-zero post-process toggle in your engine is better, takes a few lines, and works on live frames and every future build. Any free image editor does it, and so does the grayscale accessibility filter in most operating systems. Make it one keystroke, because a check that needs setup runs once.

My game is stylized and flat. Does value structure still apply?

It applies harder. Flat and low-resolution art has fewer pixels per shape, so value separation does nearly all the work and no detail rescues a bad band. Sort your palette by lightness and confirm different layers draw from different parts of the sort. Palettes crowded in the middle are why flat art goes muddy at play size.

Are these just opinions about what looks good?

Six of the eight carry a number and a pass condition, so they sit closer to assertions than opinions. None tells you whether a scene is beautiful. A game can pass all eight and still be generic, and at that point you have exhausted what specification does.

Can I fix these after the art is already made?

Mostly. Sort failures by scope. Layer-wide problems are cheap, since a tint or value remap applies to a whole band. Single-asset problems cost that asset. Character-wide problems are the expensive case, because a cast in the wrong band is wrong in every room at once. That is the argument for writing bands down first.