Por Qué HSB Le Gana a RGB en Juegos de Adivinar Colores
Cuando construimos Toon Tone, la decisión de interfaz más importante fue: ¿qué modelo de color representan los controles? RGB es el default obvio — es como toda pantalla renderiza píxeles — pero también es catastróficamente incorrecto para un juego que pide a humanos adivinar colores. Este post explica por qué elegimos HSB en su lugar, y por qué todo juego de adivinar colores debería hacer lo mismo.
Los dos modelos de color, en 30 segundos
RGB describe un color por cuánta luz roja, verde y azul emite. Cada canal va de 0 a 255. (255, 0, 0) es rojo puro. (255, 255, 0) es amarillo porque luz roja y verde combinadas dan amarillo en una pantalla. El modelo es correcto para hardware: es literalmente lo que hacen los subpíxeles de tu monitor.
HSB (también llamado HSV) describe un color por tono (0–360°, dónde en la rueda de colores), saturación (0–100, qué tan vivo) y brillo (0–100, qué tan claro). (0, 100, 100) es el mismo rojo puro. (60, 100, 100) es amarillo porque giraste el dial del tono 60 grados. El modelo es incorrecto para hardware pero correcto para la intuición humana.
Tres razones por las que RGB es incorrecto para un juego de adivinar color
1. RGB no encaja con cómo los humanos describen el color
Pídele a alguien que describa un color y dirá "un rojo más oscuro" o "un amarillo más anaranjado" o "un azul desgastado". Nadie dice "un color con 30% más verde". Hasta los diseñadores profesionales, que aprenden RGB el primer día, hablan de color en términos HSB. El vocabulario del color es un vocabulario de tono, viveza y brillo — tres perillas, no tres intensidades de luz.
Si un control no encaja con el modelo mental del jugador, el jugador tiene que hacer aritmética mental para usarlo. Aritmética mental durante una tarea de recuerdo es la peor UX posible. Los jugadores de Toon Tone necesitan meter un color recordado en la interfaz lo más rápido posible; HSB les permite hacerlo en un paso (girar el tono), RGB los obliga a hacerlo en tres.
2. Los controles RGB no se comportan linealmente como parece que deberían
Arrastra el canal rojo de 100 a 200 y la muestra apenas cambia. Arrastra el verde de 100 a 200 y la muestra salta a una familia totalmente diferente. El ojo no es igualmente sensible a los tres primarios — el verde domina el brillo percibido, el azul aporta menos. Los controles RGB se ven idénticos pero producen deltas visuales muy diferentes por unidad movida.
Para un juego de adivinanzas, esa asimetría es fatal. Un jugador se pasa del verde en 20 y la muestra queda irreconocible; el mismo exceso en rojo apenas se nota. El puntaje se vuelve injusto entre tonos.
3. RGB no aísla las dimensiones que a los jugadores realmente les importan
Los jugadores que fallan un intento quieren saber en qué dimensión se equivocaron. Con HSB, el desglose del puntaje es limpio: "acertaste el tono, pero estuviste 20 puntos demasiado saturado". Ese es feedback accionable. Con RGB, el desglose es "estuviste 14 alto en rojo, 22 bajo en verde, 8 alto en azul" — sin sentido para un humano.
La teoría del color enseña que tono, saturación y brillo son ejes perceptuales independientes. Los ejes RGB no son perceptuales — son hardware. Una buena UX le enseña al usuario sobre sí mismo; HSB le enseña al usuario que subestima la saturación. RGB no enseña nada.
Por qué no nos fuimos con Lab u OKLab
Una pregunta honesta con la que peleamos por una semana. Lab y OKLab son perceptualmente uniformes — distancias numéricas iguales corresponden a diferencias percibidas iguales, lo que haría el puntaje aún más justo que HSB. Pero hay dos problemas prácticos:
- Lab no es intuitivo. El canal L es brillo, pero a y b son ejes "verde-rojo" y "azul-amarillo" que ningún no especialista entiende. Los jugadores necesitarían un tutorial solo para saber hacia qué lado arrastrar.
- Lab tiene zonas fuera del gamut. Algunas tripletas Lab no corresponden a ningún color RGB visible. Controles que producen colores inválidos son una pesadilla de usabilidad.
Así que usamos HSB para la interfaz y una métrica de distancia perceptual para el puntaje por debajo — lo mejor de ambos mundos.
La función de puntaje, brevemente
Toon Tone puntúa cada intento en una escala de 0 a 10 calculando una distancia ponderada entre el intento y el objetivo en el espacio HSB:
score = 10 - 0,4 * |Δtono normalizado| - 0,3 * |Δsat| - 0,3 * |Δbrillo|El tono se pondera un poco más porque equivocarse de tono es el tipo de error más diagnóstico — un error de brillo aún acierta la familia del color; un error de tono significa que recordaste mal el personaje. Los pesos exactos están afinados para que 7,0 se sienta "acertaste la familia", 8,5 se sienta "lo bastante cerca como para que un diseñador lo acepte", y 9,5+ se sienta "ojo sobrenatural".
Qué significa esto para otros diseñadores de juegos
Si estás construyendo un juego de adivinar colores, la conclusión es simple:
- Usa controles HSB para la UX de entrada.
- Puntúa con HSB o con una métrica perceptual — nunca distancia euclidiana RGB cruda.
- Muestra el desglose por H/S/B en la tarjeta de resultado para que los jugadores aprendan en qué dimensión son débiles.
- Resiste la tentación de agregar un cuarto control para alpha o un selector de color sofisticado — tres controles es la complejidad correcta para una tarea de recuerdo.
Si eres un jugador preguntándose por qué Toon Tone se siente distinto de otros juegos de color que has probado — esta es la mayor parte de la razón.