Color guess games can work fully with RGB inputs when the interface accepts three decimal channel values per round and converts them into the same internal tuple used for scoring. The RGB Guessing Game confirms that yes, a color guess game can work with RGB: it accepts three whole-number channels between 0 and 255, runs each estimate through a strict per-channel error rule, and tracks a deterministic score across five swatches. The game accepts both decimal RGB and CSS hexadecimal notation so that color guess workflows using either form resolve to the exact same red-green-blue comparison. Because the answer is rendered to a Canvas element rather than stored in page text, ARIA labels, data attributes, or inline style, normal play does not publish the exact target tuple. Both notations are converted to a canonical three-integer tuple before per-channel absolute error is calculated, which means an RGB entry and an equivalent HEX entry share one miss signature. The interface prevents accidental answer disclosure while still letting you type your best estimate of red, green, and blue in whichever form you find fastest.
What RGB input means in this game
Decimal RGB input is one typed-input mode in this game. Each guess places three whole numbers between 0 and 255 into the form, one for red, one for green, and one for blue. Channels must be integers, so fractional values like 127.5 are rejected by the parser and produce no change to the underlying round state. Out-of-range entries, negatives, and numbers above 255 follow the same path: the form simply will not submit as a valid attempt, leaving you free to correct the entry without spending a miss.
The parser still follows the W3C CSS Color Module Level 4 hexadecimal notation rules when you select HEX input. HEX entries must include the leading hash and accept either the three-digit or the six-digit form. Three-digit notation duplicates each digit, so #ABC expands to #AABBCC before scoring. Because the digits are case-insensitive, both #abc and #ABC normalize to the same three-integer tuple. After normalization, every entry, regardless of input mode, becomes one red, green, blue integer tuple and is then deduplicated against earlier attempts so that submitting "60, 180, 90" cannot be distinguished from submitting "3CB45A" for the purposes of counting a second distinct wrong color in the same round.
The dual threshold rule: how close is close enough
Color accuracy is measured through absolute channel error: |target red minus guessed red|, |target green minus guessed green|, and |target blue minus guessed blue|. To pass a swatch, the guess must satisfy two conditions at the same time. First, every individual channel error must be no more than 12. Second, the sum of all three channel errors must be no more than 24. Both inclusive limits are required, so a perfectly correct green and blue cannot rescue a red that is off by 20.
This dual rule exists because one large channel mistake would otherwise slip through. Suppose the target is "200, 50, 25" and you enter "210, 0, 200". The largest channel error is 175, which already breaks the per-channel limit, and the total error of 10 + 50 + 175 equals 235, which also blows past 24. The dual rule fails on both counts, which is the intended behavior. Now suppose the target is "150, 150, 150" and you enter "162, 162, 162". Each channel error is 12, which is within the per-channel limit, but the sum is exactly 36, which fails the sum rule because the sum must be 24 or less. The dual threshold exists precisely to keep honest estimators honest without confusing large visual mistakes with small estimation noise.
Successful swatches award exactly 200 points and unlock the next round in the fixed five-round queue. The game keeps no partial credit within a swatch, so an estimate that satisfies the dual rule scores identically to a byte-accurate entry. Visual accuracy inside the limits gives the same outcome as perfect channel recognition, which keeps the 1,000-point ceiling achievable without pixel-perfect typing.
How to play an RGB round
The five-round flow is the same on every play, so the rhythm can be rehearsed before your first run.
- Study the current Canvas swatch and decide which mode, decimal RGB or CSS HEX, will be fastest for your eye and your entry habits.
- Enter three 0–255 integers into the red, green, and blue fields, or type a #RGB or #RRGGBB value into the HEX field with the leading hash included.
- Submit the estimate by tabbing through the native format buttons, the channel fields, and the submit action, then pressing Enter from the form to commit.
- Read the per-channel error feedback: every channel error, the largest channel error, and the sum of the three channel errors appear together.
- Adjust your estimate toward the displayed error pattern — if red is the largest deviation, push the red channel up or down until it sits inside the 12-unit limit on the next attempt.
- Identify all five swatches before two distinct wrong colors lock any round; each successful swatch adds exactly 200 points to the visible total.
- Watch the score climb to a verifiable 1,000-point perfect run only when every swatch passes within the dual threshold, ideally on the first try or a single repaired attempt.
Each input keeps a mobile-friendly touch height, and the layout switches to a single column on a narrow screen, so the rhythm carries over to a phone browser without losing access to the format buttons. Completion or deadlock moves focus to a terminal status message so the next action is unambiguous, which is the same accessibility hook the form uses for ordinary invalid entries.
RGB and HEX resolve to one tuple
Choosing between decimal RGB and CSS HEX is a matter of speed, not a different game mode. Both notations produce the same internal triple before scoring, and the second-distinct-miss lock uses that canonical triple. If you submit "0, 128, 255" and then resubmit the same color as "#0080FF", the game counts it as one miss rather than two. This cross-format deduplication is also why moving from a decimal entry to an equivalent HEX repeat does not spend your repair attempt, because both inputs normalize to the same canonical tuple before the miss counter sees them.
The evidence package follows W3C CSS Color Module Level 4 rules for hexadecimal notation, including the digit-duplication rule for #RGB and case-insensitive hex digits. The MDN hex-color reference confirms that the three- and six-digit forms, digit duplication, and case behavior all map to one sRGB triple once normalized. The MDN rgb() reference independently cross-checks the same 0-to-255 integer range that decimal entries must respect, so the decimal side of the parser runs against the same boundary conditions as the HEX side.
Quick comparison: RGB vs HEX input modes
| Property | Decimal RGB mode | CSS HEX mode |
|---|---|---|
| Channel format | Three 0–255 integers | #RGB or #RRGGBB string |
| Required syntax | Whole numbers only | Leading hash plus hex digits |
| Three-digit shorthand | Not applicable | Each digit duplicated (#ABC → #AABBCC) |
| Case handling | Not applicable | Case-insensitive (#abc equals #ABC) |
| Internal representation | Three integers | Normalized to three integers |
| Miss counting | Same canonical tuple counted once across formats |
Score, deadlock, and the exact 1,000-point run
The score formula is simple by design: 200 points per successful swatch, five swatches, 1,000 points. There are no bonus points, no decay, and no carry from failed attempts, so the only way to reach the 1,000-point ceiling is to clear every swatch. A lock from two distinct wrong colors freezes the active round until Restart, but it does not reduce the score banked from rounds you cleared before the lock, which is what lets the per-round state and the running total stay cleanly separated.
Lock conditions are deliberately transparent. The first different normalized wrong color leaves one repair attempt. Repeating the same color does not consume the second chance, even when the first entry used decimal RGB and the repeat used an equivalent HEX code. A second different wrong color locks the round and moves focus to a terminal status message. While the shared Boss overlay is visible, every input edit, mode change, submission, and Restart returns without altering local or scored state, which preserves the integrity of an in-progress run when the overlay appears mid-guess.
Best-score handling remains in the browser along with the round state. There is no upload, account, model call, remote color service, or new dependency, so a perfect 1,000-point run is reproducible without any external state. Invalid syntax, missing channels, fractions, negative values, values above 255, deadlocked states, and completed states do not alter the business state, which keeps accidental keystrokes from quietly changing your run before you have committed any estimate.