Warum HSB bei Farb-Ratespielen RGB schlägt

Als wir Toon Tone gebaut haben, war die wichtigste Interface-Entscheidung: welches Farbmodell stellen die Regler dar? RGB ist der offensichtliche Default — so rendert jeder Bildschirm Pixel — aber für ein Spiel, in dem Menschen Farben raten sollen, ist es katastrophal falsch. Dieser Beitrag erklärt, warum wir stattdessen HSB gewählt haben, und warum jedes Farb-Ratespiel dasselbe tun sollte.

Die zwei Farbmodelle, in 30 Sekunden

RGB beschreibt eine Farbe danach, wie viel rotes, grünes und blaues Licht sie abgibt. Jeder Kanal läuft von 0 bis 255. (255, 0, 0) ist reines Rot. (255, 255, 0) ist Gelb, weil rotes und grünes Licht zusammen auf einem Bildschirm Gelb ergibt. Das Modell stimmt für Hardware: das machen die Subpixel deines Monitors buchstäblich.

HSB (auch HSV genannt) beschreibt eine Farbe durch Farbton (0–360°, wo auf dem Farbkreis), Sättigung (0–100, wie kräftig) und Helligkeit (0–100, wie hell). (0, 100, 100) ist dasselbe reine Rot. (60, 100, 100) ist Gelb, weil du das Farbton-Rad um 60 Grad gedreht hast. Das Modell ist für Hardware falsch, aber für die menschliche Intuition richtig.

Drei Gründe, warum RGB für ein Farb-Ratespiel falsch ist

1. RGB passt nicht dazu, wie Menschen Farbe beschreiben

Bitte jemanden, eine Farbe zu beschreiben, und er sagt "ein dunkleres Rot" oder "ein orangeres Gelb" oder "ein ausgewaschenes Blau". Niemand sagt "eine Farbe mit 30 % mehr Grün". Sogar professionelle Designer, die RGB am ersten Tag lernen, sprechen in HSB-Begriffen über Farbe. Das Vokabular der Farbe ist ein Vokabular aus Farbton, Sättigung und Helligkeit — drei Regler, nicht drei Lichtintensitäten.

Wenn ein Regler nicht zum mentalen Modell des Spielers passt, muss der Spieler im Kopf rechnen, um ihn zu benutzen. Kopfrechnen während einer Erinnerungsaufgabe ist die schlechtest mögliche UX. Toon-Tone-Spieler müssen eine erinnerte Farbe so schnell wie möglich ins Interface bringen; HSB lässt sie das in einem Schritt machen (Farbton drehen), RGB zwingt sie zu drei Schritten.

2. RGB-Regler verhalten sich nicht linear, so wie sie aussehen

Zieh den Rot-Kanal von 100 auf 200, und das Farbfeld ändert sich kaum. Zieh Grün von 100 auf 200, und das Feld springt in eine völlig andere Familie. Das Auge ist nicht gleich empfindlich für die drei Grundfarben — Grün dominiert die wahrgenommene Helligkeit, Blau trägt am wenigsten bei. RGB-Regler sehen identisch aus, erzeugen aber wild unterschiedliche visuelle Sprünge pro Einheit.

Für ein Ratespiel ist diese Asymmetrie fatal. Ein Spieler schießt 20 Punkte über Grün hinaus, und das Farbfeld ist unkenntlich; derselbe Überschuss bei Rot fällt kaum auf. Die Punktevergabe wird zwischen Farbtönen ungerecht.

3. RGB isoliert nicht die Dimensionen, die Spieler wirklich interessieren

Spieler, die einen Tipp verfehlen, wollen wissen, in welcher Dimension sie danebenlagen. Mit HSB ist die Score-Aufschlüsselung sauber: "du hast den Farbton getroffen, aber warst 20 Punkte zu sättigt". Das ist verwertbares Feedback. Mit RGB ist die Aufschlüsselung "du warst 14 zu hoch im Rot, 22 zu niedrig im Grün, 8 zu hoch im Blau" — für einen Menschen sinnlos.

Die Farbtheorie lehrt, dass Farbton, Sättigung und Helligkeit unabhängige perzeptuelle Achsen sind. RGB-Achsen sind nicht perzeptuell — sie sind Hardware. Gute UX lehrt den Nutzer etwas über sich selbst; HSB lehrt den Nutzer, dass er die Sättigung unterschätzt. RGB lehrt nichts.

Warum nicht Lab oder OKLab?

Eine ehrliche Frage, mit der wir eine Woche gerungen haben. Lab und OKLab sind perzeptuell uniform — gleiche numerische Abstände entsprechen gleichen wahrgenommenen Unterschieden, was die Punktevergabe noch fairer machen würde als HSB. Aber es gibt zwei praktische Probleme:

• Lab ist nicht intuitiv. Der L-Kanal ist Helligkeit, aber a und b sind "Grün-Rot"- und "Blau-Gelb"-Achsen, die kein Nicht-Spezialist versteht. Spieler bräuchten ein Tutorial nur, um zu wissen, in welche Richtung sie ziehen sollen.
• Lab hat Out-of-Gamut-Zonen. Manche Lab-Tripel entsprechen keiner darstellbaren RGB-Farbe. Regler, die ungültige Farben erzeugen, sind ein Usability-Albtraum.

Also nutzen wir HSB fürs Interface und eine perzeptuelle Distanzmetrik für die Punktevergabe darunter — das Beste aus beiden Welten.

Die Score-Funktion, kurz

Toon Tone bewertet jeden Tipp auf einer Skala von 0–10, indem es einen gewichteten Abstand zwischen Tipp und Ziel im HSB-Raum berechnet:

score = 10 - 0,4 * |Δfarbton normiert| - 0,3 * |Δsat| - 0,3 * |Δhelligkeit|

Der Farbton wird etwas höher gewichtet, weil ein Farbton-Fehler die diagnostisch wertvollste Art von Miss ist — ein Helligkeitsfehler trifft die Farbfamilie noch; ein Farbtonfehler bedeutet, dass du die Figur falsch erinnert hast. Die genauen Gewichte sind so eingestellt, dass 7,0 sich nach "Familie getroffen" anfühlt, 8,5 nach "nah genug, dass ein Designer es durchwinken würde", und 9,5+ nach "geschultes Auge".

Was das für andere Spieledesigner bedeutet

Wenn du ein Farb-Ratespiel baust, ist die Erkenntnis einfach:

• Nutze HSB-Regler für die Input-UX.
• Bewerte mit HSB oder einer perzeptuellen Metrik — niemals rohe RGB-Euklidische-Distanz.
• Zeig die Aufschlüsselung nach H/S/B in der Ergebniskarte, damit Spieler lernen, in welcher Dimension sie schwach sind.
• Widersteh der Versuchung, einen vierten Regler für Alpha oder einen schicken Color Picker hinzuzufügen — drei Regler sind die richtige Komplexität für eine Erinnerungsaufgabe.

Wenn du ein Spieler bist, der sich fragt, warum sich Toon Tone anders anfühlt als andere Farb-Spiele, die du ausprobiert hast — das ist der größte Teil des Grundes.

Selbst ausprobieren