Perfect Color Was Never Supposed to Have Modes

There's no menu in this game right now. You load it, you see a target color swatch, and you drag red, green, and blue sliders until your mix matches it as closely as you can, then submit. That's one mode, no selection screen, because there's only one thing to select. I keep building these small, single-idea games back to back and I think it's becoming a pattern worth naming: get the core loop working and shippable before spending any time on a menu system for choices that don't exist yet.

Why sliders instead of a color wheel or hex input

I considered a couple of other input methods before landing on three separate RGB sliders. A color wheel looks nicer but makes it too easy to eyeball a close match through spatial memory of "roughly here on the wheel" rather than actually reasoning about the color's composition. A raw hex code input would remove the game entirely — at that point you're just typing in an answer. Three independent sliders force you to actually think in terms of how much red, green, and blue are in the target, which is a more honest test of color perception than either alternative, even if it's objectively the least elegant-looking option of the three.

Scoring by channel, not by overall distance

Accuracy is scored per channel — how far off your red is, how far off your green is, how far off your blue is — rather than collapsing everything into one combined distance number up front. That matters more than it sounds like it should. A single blended score can hide exactly where you went wrong: you could be dead-on for red and blue but significantly off on green, and a combined number would just tell you "close, but not quite" without pointing at the actual mistake. Showing the per-channel deltas turns a vague "try again" into something you can actually learn from between attempts, which is the difference between a game that teaches you something about color and one that's just a slot machine for a score number.

The stepper buttons almost didn't happen

For the first version I shipped with just the sliders, and testing it myself, the last few points of precision were genuinely annoying to nail down — dragging a slider to land on an exact value is imprecise by nature, especially on a trackpad. I added small increment/decrement stepper buttons next to each slider specifically for that final fine-tuning, after fighting my own UI for a solid ten minutes trying to get a swatch within a couple of points of a target. Sliders are the right tool for getting close fast; they're the wrong tool for the last mile, and I should've built both from the start instead of discovering it the annoying way.

What's already in the back of my mind, even though none of it exists yet: a version where you have to remember the color instead of matching it side by side, and a fast-paced timed variant for people who'd rather chase a clock than perfect accuracy. Neither is built. I'm noting the idea here mostly so that if this game ever does grow into something with actual modes, there's a record that the multi-mode idea existed from nearly day one — it just wasn't going to be day one's problem to solve.

Rendering the swatch consistently was its own small fight

Something I didn't expect going in: the same RGB value doesn't necessarily look identical across every monitor and browser rendering path, and for a game entirely about matching a color by eye, that's a real problem rather than a nitpick. Color profiles, gamma handling, and display calibration all sit between "the number my code says" and "the color a specific person is actually looking at." I can't fix someone's uncalibrated monitor from inside a browser tab, but I made sure the game renders both the target swatch and the player's mix through the exact same code path with nothing display-specific applied to just one of them, so whatever shift a person's screen introduces, it at least introduces it equally to both colors being compared. The comparison staying fair matters more than either color being "objectively" correct on any specific display.

I also thought seriously about color vision deficiency here, since a game that's purely about distinguishing color values is about as unfriendly as it gets for anyone with red-green color blindness, which is a meaningful chunk of any general audience. The per-channel numeric deltas I mentioned earlier end up doing double duty here — someone who can't visually separate two close reds can still read the actual channel numbers and reason about the mix analytically instead of purely by eye. It's not a complete accessibility solution, but it's a real one that fell out of a decision I'd made for a completely different reason.

Choosing target colors so the game isn't secretly easy

Randomly generating a target color across the full RGB range sounds fair, but it isn't, because human color perception isn't evenly sensitive across that whole range. Small shifts in the middle of the brightness spectrum are easy to spot; equally-sized numeric shifts in a very dark or very washed-out color are much harder to see and correct for by eye, which means a purely random target generator would quietly produce some rounds that are nowhere near as fair as their RGB distance from correct would suggest. I ended up biasing target generation away from the extremes — very dark, near-black targets and very light, near-white ones — specifically because those are the cases where "technically random" and "actually fair to a human eye" stop meaning the same thing.

None of this is complicated engineering. It's mostly a string of small decisions — how to input a color, how to score it, how to generate a fair target — where the naive first answer to each one was slightly wrong in a way that only showed up once I actually sat down and tried to beat the game myself. That's turning into the real pattern across everything I've shipped this month: the design doesn't get right on paper, it gets right by playing the rough draft enough times to notice where it quietly cheats you.