Por Que HSB Ganha de RGB em Jogos de Adivinhar Cores

Quando construímos o Toon Tone, a decisão de interface mais importante foi: qual modelo de cor os controles representam? RGB é o padrão óbvio — é como toda tela renderiza pixels — mas também é catastroficamente errado para um jogo que pede que humanos adivinhem cores. Este post explica por que escolhemos HSB no lugar, e por que todo jogo de adivinhar cores deveria fazer o mesmo.

Os dois modelos de cor, em 30 segundos

RGB descreve uma cor por quanta luz vermelha, verde e azul ela emite. Cada canal vai de 0 a 255. (255, 0, 0) é vermelho puro. (255, 255, 0) é amarelo porque luz vermelha e verde combinadas faz amarelo numa tela. O modelo está correto para hardware: é literalmente o que os subpixels do seu monitor fazem.

HSB (também chamado HSV) descreve uma cor por matiz (0–360°, onde na roda de cores), saturação (0–100, quão vívida) e brilho (0–100, quão clara). (0, 100, 100) é o mesmo vermelho puro. (60, 100, 100) é amarelo porque você girou o dial do matiz 60 graus. O modelo está errado para hardware mas certo para a intuição humana.

Três razões pelas quais o RGB é errado para um jogo de adivinhar cor

1. RGB não combina com como humanos descrevem cor

Pergunte a alguém para descrever uma cor e ele vai dizer "um vermelho mais escuro" ou "um amarelo mais alaranjado" ou "um azul lavado". Ninguém diz "uma cor com 30% mais verde". Até designers profissionais, que aprendem RGB no primeiro dia, falam sobre cor em termos HSB. O vocabulário de cor é um vocabulário de matiz, vivacidade e brilho — três botões, não três intensidades de luz.

Se um controle não combina com o modelo mental do jogador, o jogador precisa fazer aritmética mental para usá-lo. Aritmética mental durante uma tarefa de recordação é a pior UX possível. Os jogadores de Toon Tone precisam colocar uma cor lembrada na interface o mais rápido possível; HSB deixa eles fazerem isso em um passo (girar o matiz), RGB faz eles fazerem isso em três.

2. Os controles RGB não se comportam linearmente do jeito que parecem que deveriam

Arraste o canal vermelho de 100 a 200 e a amostra mal muda. Arraste o verde de 100 a 200 e a amostra salta para uma família totalmente diferente. O olho não é igualmente sensível às três primárias — verde domina o brilho percebido, azul contribui menos. Os controles RGB parecem idênticos mas produzem deltas visuais muito diferentes por unidade movida.

Para um jogo de adivinhação, essa assimetria é fatal. Um jogador ultrapassa o verde em 20 e a amostra fica irreconhecível; o mesmo overshoot no vermelho mal registra. A pontuação fica injusta entre matizes.

3. RGB não isola as dimensões com que os jogadores realmente se importam

Jogadores que erram um palpite querem saber em qual dimensão erraram. Com HSB, o detalhamento da pontuação fica limpo: "você acertou o matiz, mas estava 20 pontos saturado demais". Esse é um feedback acionável. Com RGB, o detalhamento é "você estava 14 acima no vermelho, 22 abaixo no verde, 8 acima no azul" — sem sentido para um humano.

A teoria das cores ensina que matiz, saturação e brilho são eixos perceptuais independentes. Os eixos RGB não são perceptuais — são hardware. Uma boa UX ensina o usuário sobre si mesmo; HSB ensina o usuário que ele subestima a saturação. RGB não ensina nada.

Por que não fomos com Lab ou OKLab

Uma pergunta honesta com a qual lutamos por uma semana. Lab e OKLab são perceptualmente uniformes — distâncias numéricas iguais correspondem a diferenças percebidas iguais, o que tornaria a pontuação ainda mais justa que HSB. Mas existem dois problemas práticos:

• Lab não é intuitivo. O canal L é brilho, mas a e b são eixos "verde-vermelho" e "azul-amarelo" que nenhum não especialista entende. Os jogadores precisariam de um tutorial só para saber em que direção arrastar.
• Lab tem zonas fora do gamut. Algumas triplas Lab não correspondem a nenhuma cor RGB exibível. Controles que produzem cores inválidas são um pesadelo de usabilidade.

Então usamos HSB para a interface e uma métrica de distância perceptual para a pontuação por baixo — o melhor dos dois mundos.

A função de pontuação, brevemente

Toon Tone pontua cada palpite numa escala de 0 a 10 calculando uma distância ponderada entre palpite e alvo no espaço HSB:

score = 10 - 0,4 * |Δmatiz normalizado| - 0,3 * |Δsat| - 0,3 * |Δbrilho|

O matiz é ponderado um pouco mais porque errar o matiz é o tipo de erro mais diagnóstico — um erro de brilho ainda acerta a família da cor; um erro de matiz significa que você lembrou do personagem errado. Os pesos exatos estão ajustados para fazer 7,0 parecer "acertou a família", 8,5 parecer "perto o bastante para um designer aceitar", e 9,5+ parecer "olho sobrenatural".

O que isso significa para outros designers de jogo

Se você está construindo um jogo de adivinhar cores, a conclusão é simples:

• Use controles HSB para a UX de input.
• Pontue com HSB ou uma métrica perceptual — nunca distância euclidiana RGB pura.
• Mostre o detalhamento por H/S/B no cartão de resultado para que os jogadores aprendam em qual dimensão são fracos.
• Resista à tentação de adicionar um quarto controle para alpha ou um seletor de cor sofisticado — três controles é a complexidade certa para uma tarefa de recordação.

Se você é um jogador se perguntando por que Toon Tone parece diferente de outros jogos de cor que tentou — essa é a maior parte da razão.

Experimente