10 Background Art Mistakes That Cost Indie Games Their Look

A background that is failing rarely tells you what is wrong with it. The room looks correct in a file browser and wrong the moment a character stands in it. The developer reports something vague, the artist repaints something else, and the room still reads as amateur.

Nearly every one of those problems is diagnosable. Below are ten mistakes that cost small 2D games their look, each with the symptom, the reason it happens, and the fix. Most are specification errors rather than drawing errors, so a programmer can find and correct them without touching a brush. Figures come from one measured, shipped room set, checked September 2026. This is the blog of Makko, an AI-powered 2D game art studio, named once below where it is the natural answer.

The short version. Three of these ten cause most of the damage: the background was commissioned as one picture instead of a set of pieces, detail was painted into the horizontal band where characters walk, and the room was never checked in grayscale at play size. Fix those first. The other seven are budget and motion errors that surface later and cost more to unwind.

How these ten were picked

Four filters. A mistake earned a place only by passing all four.

• It has a visible symptom. Something a developer or player can point at. "The room feels off" is not a diagnosis.
• A non-artist can find it. Every check below is arithmetic, a file property, a grayscale conversion, or an engine readout.
• It gets more expensive the longer it sits, usually by compounding across every room already made.
• It is common in small-team 2D art rather than exotic.

Entries run in the order the mistakes get made.

1. The background is one image instead of a room made of pieces

Symptom. Every change is a full repaint. A longer corridor, a second exit, a damaged version: each one comes back as a new commission at the original price.

Why it happens. A background gets requested the way a picture gets requested: one image, one file, one approval. The artist composes for a viewer standing still, with detail spread evenly.

The fix. Specify the assembly before anyone renders a pixel: how many middle sections, how many top and bottom framing pieces, how many variants of each, where the seams fall. One corridor in the measured set is twelve assets, and the eleven extras are not rejected attempts but sections, framing pieces and variants. One room becomes a short corridor, a long corridor, or a different stretch of ship. The room model and its order of operations is the long version.

2. Detail is painted into the band where characters walk

Symptom. The character is hardest to see in the middle of the screen, where gameplay happens, and easiest to see near the edges. Players lose track of themselves in fights.

Why it happens. The most interesting part of a picture is usually its center, so a good illustrator puts the best material there. Nobody said gameplay occupies the same pixels.

The fix. Measure the play band from your camera: character height plus the camera's vertical range of positions gives two Y values. Then require the framing pieces to carry no rendered detail between them. Production does this at the file level, not as a note about taste. One framing piece in the measured set is 2,048 pixels on a side, and 1,147 of those pixels through its middle are fully transparent. Not dimmed, not blurred. Absent. A transparent center cannot compete with gameplay at any scroll rate, and a script can check it.

3. The character gets an outline because the room has no value separation

Symptom. Someone proposes a rim light, a thicker outline, or a brighter palette for the cast. That proposal is the tell: the fix is going onto the wrong asset.

Why it happens. The character is what you are looking at when the problem appears. Separation comes from difference, and the room owns three of the four levers: value, detail density and saturation. The character owns only edge treatment.

The fix. Composite a character into the room, convert to grayscale, shrink to real screen size, look for two seconds. If you cannot find the character instantly, change the room. Decide once whether the cast reads light on dark or dark on light, then hold it everywhere. Color is the lever that fools you into thinking separation is fine, and grayscale removes it.

4. Every location is a new painting

Symptom. Your background count matches your location list one to one, and the schedule is roughly double what the game can afford.

Why it happens. The design document lists places, the script adds scenes, each scene quietly acquires a background, and nobody runs the division. Backgrounds equal distinct places divided by the locations you pull from each painted room, and projects work on the numerator only.

The fix. Group by architecture before commissioning. Four corridors with different signage are one corridor with three dressing sets. Then push the denominator with the cheap multipliers: prop swaps, camera crops from a source authored wider than the frame, and runtime lighting. Five rooms with three variants each reads as a bigger game than eight one-off pictures and costs less. Anything that changes the architecture's silhouette or the walkable area is a second room with a variant's name on the ticket.

5. The same room is lit the same way in every scene

Symptom. Players describe the game as small while your asset folder says otherwise. The same corridor appears in hour one and hour four looking identical, and registers as one place visited twice.

Why it happens. Lighting gets treated as part of the painting instead of a runtime pass. Once baked in, changing it means a repaint, so nobody changes it.

The fix. Keep baked shadows soft in any room you intend to relight, then use engine lights and grades freely. A hue shift plus a change of key reads as a different place more often than developers expect, at no cost per room. The condition is consistency: if the ceiling is lit from a source the floor ignores, a second lighting state exposes the disagreement. Systems that bake a whole collection at once, as Makko does, hold light direction consistent across a room set.

6. The oversized source ships instead of the flattened final

Symptom. Your download is several times the size the art justifies and nothing on screen looks better for it. Room transitions may hitch.

Why it happens. The file the artist delivers is the file that enters the build, because nobody defined a step between them. Unflattened layers and a skipped optimization pass are invisible in a file browser.

The fix. Make flattening and optimization a named, required step. In the measured set, finished 1920 x 1080 rooms land between 328 and 468 KB while the 2560 x 1440 sources run 2.7 to 3.8 MB. Pixel count rises about 1.8 times and file size roughly eight, so processing accounts for a factor of four and a half by itself.

7. The art is authored at a resolution that buys nothing

Symptom. A 4K source folder, a long render queue, and no plan that uses either. Or the opposite: sources authored at exactly ship size, so the first camera crop anyone asks for is a repaint.

Why it happens. Authoring resolution and shipping resolution collapse into one number. Treat them as one and you end up strict on both, producing soft art, or generous on both, paying render time for pixels the resample discards.

The fix. Give the artist two numbers. Ship what the camera displays. Author about 1.3 times that linear, as the measured set does at 2560 x 1440 against a 1920 x 1080 target, and square at 2048 x 2048 for anything that tiles. Above twice ship resolution, name the plan that consumes the extra pixels or stop paying for them. The two-number resolution spec covers the headroom cases.

8. The cast gets budgeted and the rooms do not

Symptom. Someone spent a week packing sprite sheets tighter and the build still runs out of texture memory on the target hardware.

Why it happens. Sprite sheets have packing tools and a culture of optimization around them. Backgrounds are single files that look cheap on disk, so they never get counted.

The fix. Budget rooms in resident megabytes, not file sizes. Uncompressed, a 1920 x 1080 background occupies 7.91 MiB of video memory against 2.38 MiB for a 600 x 1040 character sheet, so one room is roughly three and a half character sheets. That room was 328 KB on disk, so its memory cost is twenty-five times its file size and your compression settings moved none of it. Check whether your engine applies GPU block compression to backgrounds, since many pipelines decompress to full RGBA by default.

9. Parallax is applied to something the player reads as fixed

Symptom. Testers report that the world tilts, or that the game makes them queasy, and nobody can point at the layer doing it. Lowering every scroll rate helps slightly and fixes nothing.

Why it happens. Parallax gets applied to a layer list rather than a depth model. A floor texture, a contact shadow, a horizon line or an interface element ends up on a non-1.0 rate because it lived on a background layer. When something the brain filed as stationary drifts, the brain reports the world as rotating.

The fix. Keep an explicit locked list. The ground plane and everything touching it sits at 1.0, the plane the camera tracks. Interface sits at 0.0, the horizon at 0.0 or very close. Drive the rest from per-axis camera delta and zero the axis with no camera motion behind it. Test at maximum speed and on a rapid reversal.

10. The foreground moves fast enough to be unpleasant

Symptom. One layer strobes or sweeps as it passes, worst when the player dashes. Some testers stop playing within ten minutes and cannot say why.

Why it happens. Foreground rate gets tuned for apparent closeness and speed is the obvious dial. The spread around 1.0 is asymmetric: a back layer at 0.1 is calm, while a foreground at 1.6 reads as an assault. That nearest layer also tends to carry fine, high-contrast detail, and detail strobes.

The fix. Cap the fastest layer near 1.25 and default to 1.15. For more closeness, make the element larger and softer rather than faster. Budget contrast inversely to rate: a foreground at 1.15 holds two or three soft shapes anchored to the edges, not a railing. Back 0.15, mid 0.5, play 1.0, foreground 1.15 is a working default. The band model and the four causes of parallax motion sickness has the rest.

The ten at a glance

How to run the diagnosis in one sitting

Copy this and run it against one room. Ten minutes, and it isolates which of the ten you have. Run steps 1 and 2 on the assembled room, not the pieces, since a quiet section plus a quiet framing piece can still composite into a busy band.

# ROOM AUDIT - [ROOM NAME]

1. GRAYSCALE AT PLAY SIZE
   cast not instantly findable    -> mistake 3

2. MASK THE PLAY BAND  Y [____] to [____]
   anything reading as a subject  -> mistake 2
   framing piece not transparent  -> mistake 2

3. COUNT THE PIECES
   this room is one asset         -> mistake 1
   rooms with zero variants       -> mistake 4
   one lighting state per room    -> mistake 5

4. READ TWO NUMBERS
   disk [____] KB  (finals 328-468 KB)
   resident w x h x 4  (7.91 MiB at 1080p)
   source dimensions in build     -> mistake 6
   author > 2x ship, no plan      -> mistake 7
   rooms x 7.91 > texture budget  -> mistake 8

5. MAX CAMERA SPEED, THEN REVERSE
   ground / horizon / UI drifting -> mistake 9
   fastest layer above 1.25       -> mistake 10

Frequently asked questions

Which of these should I fix first on a game already in production?

Mistake 3, because testing it costs nothing. Pick light on dark or dark on light, run the grayscale check on every room you have, and list the failures. Then mistake 6: pulling sources out of the build shrinks the download immediately. Mistake 1 is expensive to correct late, so apply the room model to new rooms and leave finished ones alone.

Can I diagnose these without an artist?

All ten, yes. Fixing 2, 3, 5 and 10 means changing art, so an artist does that work, but the diagnosis is arithmetic and file properties every time. That matters in a revision request. "The framing piece carries rendered detail between Y 400 and Y 720" is a defect report. "The room feels busy" is an opinion that drifts across a twelve-asset set.

My character looks pasted on top of the room. Which mistake is that?

Usually none of them. Pasted-on is a contact problem rather than a separation problem: a character with no shadow, no ground occlusion and no color influence from the room reads as a cutout however good the rendering. Add a contact shadow and look again. If it persists, compare light direction on the character against the room's.

How many of these does a typical small game have?

Four or five, and they cluster. A project that commissioned pictures instead of room sets tends to have 1, 2 and 4 together, since all three follow from one brief. A project with good structure that never checked memory tends to have 6, 7 and 8.

Why does this say MiB and not MB?

Because memory and storage are counted in different bases. A mebibyte, MiB, is 1,048,576 bytes, or two to the twentieth. A megabyte, MB, is 1,000,000 bytes. Memory is physically addressed in powers of two, so every engine profiler reports the binary figure, and the numbers here match what Godot, Unity or Unreal will show you. Storefronts and drive manufacturers use the decimal one instead. At this scale the two differ by about five percent, so the same 1920 by 1080 background is 7.91 MiB and 8.29 MB. Same pixels, two labels. It is the same reason a drive sold as 1 TB shows up as 931 GB.