Una decisión cromática propaga restricciones
Cómo funciona Colors
Empiezas controlando la región conectada con la esquina superior izquierda. En cada turno eliges un color. Toda tu región cambia a ese color y absorbe las casillas adyacentes conectadas que ya lo tenían. El objetivo es conquistar el tablero entero.
La mecánica se aprende en segundos, pero las decisiones tienen efecto acumulativo. Un color atractivo ahora puede aislar una zona y obligarte a gastar varios movimientos adicionales.
La familia Color Flood
Color Flood, Flood-It y otros nombres describen una familia de información perfecta basada en propagación de color. Existen numerosas implementaciones digitales desde hace años y el patrón habitual es completar el tablero en el menor número posible de turnos.
No atribuimos la mecánica a una única app. Para Blupoli usamos referencias funcionales y la experiencia Android como contexto, pero código, diseño y generación son propios.
La estrategia vive en la frontera
No siempre conviene elegir el color que absorbe más casillas inmediatamente. A veces interesa llegar a una zona que abre varias regiones futuras o evitar consumir un color que necesitaremos de nuevo enseguida.
La puntuación visible está en cuántas celdas ganas; la estrategia está en qué frontera construyes.
Cuatro tamaños y cuatro dificultades
Colors estrenó un estándar que después extendimos: cuando la mecánica lo permita, queremos varios tamaños y niveles independientes. Aquí usamos 8×8, 12×12, 18×18 y 24×24.
La dificultad no cambia el tamaño. Fácil, Normal, Difícil y Experto modifican parámetros como número de colores y margen disponible en Challenge. Así un tablero grande puede ser relajado y uno pequeño exigente.
Casual y Challenge
Casual permite experimentar sin límite. Challenge añade un presupuesto de movimientos. El generador conserva una ruta de resolución válida y usa esa información como referencia para fijar un objetivo alcanzable.
No afirmamos que esa ruta sea siempre matemáticamente óptima. Sí garantizamos algo más importante: conocemos una forma de completar el tablero dentro del límite publicado.
Los errores también cuentan
Elegir un color que no absorbe ninguna celda nueva consume un movimiento. Bloquear esa acción haría la interfaz más indulgente, pero eliminaría parte de la estrategia. En un juego de optimización, una elección poco útil debe tener coste.
Eso no significa castigar errores de interacción. La UI debe dejar claro qué color está activo y hacer los controles táctiles suficientemente cómodos.
Qué validamos automáticamente
El motor incluye un selfTest() que recorre las combinaciones de tamaño y dificultad. CI comprueba que cada una puede generar una partida válida y que el límite Challenge es coherente con una resolución conocida.
- que el tablero se genera correctamente;
- que la región inicial y propagación funcionan;
- que existe una ruta conocida de resolución;
- que Challenge concede un límite coherente;
- que tamaño y dificultad siguen siendo ejes independientes.
Cómo jugar con menos movimientos
Mira más allá del siguiente color. Si dos regiones grandes del mismo color están separadas por una franja que puedes conquistar pronto, preparar su unión puede ahorrar un turno posterior.
También ayuda observar qué colores quedan en la periferia. Terminar con pequeñas islas de colores diferentes suele obligar a alternar varias veces cuando ya queda poco tablero.
Un juego visual necesita color accesible
La mecánica depende del color, así que contraste y diferenciación son requisitos funcionales. El rediseño general de temas debe cuidar que las paletas sigan siendo distinguibles y que selección o feedback no dependan de matices demasiado próximos.
Juegos parecidos
Si te atrae la planificación espacial de Colors, prueba Ataxx, centrado en expansión territorial; Hex, donde la conectividad decide; o Dots and Boxes, donde cada movimiento cambia el valor estratégico del espacio restante.
Referencias funcionales
flood-it — implementación con código fuente público
Estado actual del motor
El motor nativo está implementado y verificado, pero el manifiesto de Colors sigue en coming-soon. Documentamos el código real sin confundir implementación con publicación.
El tablero es un grafo de componentes
La región controlada nace en la esquina superior izquierda. Cada cambio de color absorbe componentes ortogonalmente conectados. Dos manchas del mismo tono no tienen el mismo valor si una toca la frontera y la otra sigue aislada.
Tamaño y dificultad están separados
El código define 8×8, 12×12, 18×18 y 24×24. Fácil usa cuatro colores, Normal cinco, Difícil seis y Experto siete. Challenge añade ocho, cinco, dos o cero movimientos de margen respecto a una guía conocida.
Challenge prueba alcanzabilidad, no optimalidad
La guía actual es greedy. El límite demuestra que existe una secuencia conocida dentro del presupuesto, pero no que esa secuencia sea matemáticamente mínima. En Experto, cero margen significa igualar o mejorar la referencia, no demostrar un óptimo global.
La seed hace la generación reproducible
Conservar la seed permite reconstruir una partida, repetir una incidencia y comparar una heurística nueva sobre exactamente el mismo tablero.
El self-test recorre dieciséis combinaciones
Los cuatro tamaños se prueban contra las cuatro dificultades. El test reproduce la guía, exige que complete el tablero y comprueba que el límite y el número de colores sean coherentes.
La propiedad correcta no es unicidad
Colors puede tener muchas secuencias válidas. Lo importante es completabilidad y un Challenge alcanzable. Es un ejemplo de por qué un solver no sirve para todos los puzzles.
La estrategia vive en la frontera
Capturar más ahora no siempre produce la mejor posición. Conviene observar qué componentes quedan accesibles, qué zonas remotas se acercan y qué colores habrá que repetir.
La dificultad podría medir topología
Dos tableros con el mismo número de colores pueden tener perfiles distintos. Herramientas internas pueden comparar seeds estables, guías greedy y búsqueda limitada para mejorar la calibración sin encarecer cada partida.
Accesibilidad y color
El color transporta estado funcional. Antes de publicar habrá que evaluar contraste, paletas alternativas y apoyos que no dependan únicamente de distinguir tonos.
El producto completo tiene más capas
Motor y self-test no resuelven onboarding, responsive, persistencia o resultados. Esa frontera conecta con terminar un puzzle es mucho más que hacerlo jugable.
La taxonomía debería describir planificación territorial
Podemos hablar de secuencias, componentes y frontera sin convertir el juego en una promesa de entrenamiento cognitivo, siguiendo la taxonomía del catálogo.
La frontera es el objeto estratégico
El porcentaje poseído cuenta lo que ya ocurrió; la frontera describe lo que puede ocurrir después. Dos posiciones con la misma superficie pueden tener futuros opuestos si una toca cuatro colores y otra queda encerrada entre dos. Una lectura fuerte del tablero empieza por acceso y conectividad.
Los componentes grandes no siempre deben capturarse primero
Una región enorme puede ser tentadora, pero absorberla puede alejar otra zona importante varios cambios. A veces conviene preparar un puente antes de consumir un color compartido. El valor de una captura depende de su posición dentro de una secuencia.
La guía conocida es un testigo, no un oráculo
Una secuencia que completa el tablero demuestra viabilidad. No necesita ser óptima para cumplir esa función. Separar “testigo de alcanzabilidad” de “solución mínima” permite mejorar el solver en el futuro sin reescribir lo que hoy garantizamos.
Las heurísticas greedy también necesitan regresiones
Un cambio pequeño en la puntuación de colores puede alterar muchas seeds. Conviene conservar un benchmark fijo y comparar longitud de guía, tiempo y reintentos. Sin esa base, una mejora visible en pocos tableros puede esconder una regresión sistemática.
Los reintentos forman parte del rendimiento
No basta con cronometrar la llamada que finalmente devuelve un tablero. El número de candidatos descartados antes de aceptar también importa. Si sube de forma sostenida, puede anticipar problemas de latencia.
Un presupuesto temporal protege la interacción
Si la búsqueda futura se vuelve más sofisticada, debe existir un límite claro para generación en cliente. Superado ese presupuesto podemos usar otra seed, una guía más barata o un fallback, en lugar de congelar la interfaz esperando una optimización.
La memoria también tiene presupuesto
Buscar secuencias puede implicar copiar tablero, región poseída y frontera. En 24×24 esas estructuras crecen. Bitsets, rollback o representaciones compactas pueden ser útiles si las métricas justifican la complejidad.
Un worker no sustituye un algoritmo eficiente
Mover trabajo a un Web Worker puede mantener responsive el hilo principal, pero añade serialización, cancelación y respuestas obsoletas. Primero hay que reducir trabajo innecesario; después decidir si la concurrencia aporta valor medible.
La cancelación evita resultados correctos para sesiones equivocadas
Si el jugador cambia dificultad o inicia otra partida, la generación anterior deja de ser útil. Un proceso pesado debe poder cancelarse y nunca sobrescribir con su resultado una sesión más nueva.
Persistir la seed mejora soporte
La seed aporta provenance para reproducir una partida. Para saves duraderos conviene guardar también el tablero o la versión de generación, porque una optimización futura podría reinterpretar la misma seed.
Versionar generación evita que el pasado cambie
Un resultado histórico debe seguir siendo reconstruible. Tamaño, dificultad, modo y versión del generador ayudan a explicar qué lógica produjo la partida aunque el código evolucione.
Casual y Challenge deben permanecer separados en estadísticas
Completar Casual en treinta movimientos y un Challenge con límite veinte no son el mismo objetivo. El resultado común debe conservar contexto para que las comparaciones no mezclen sesiones incompatibles.
Una estadística debe explicar qué compara
Movimientos frente al límite de la misma seed, frente a un intento anterior o frente al histórico personal son referencias comprensibles. Un ranking que mezcle seeds distintas puede parecer preciso y, sin contexto, decir muy poco.
Un hint puede señalar una oportunidad sin jugar por ti
La guía interna abre la puerta a ayudas, pero reproducir simplemente el siguiente color automatizaría el puzzle. Una pista mejor puede destacar un componente que quedaría accesible o explicar que cierta opción reduce demasiado la frontera.
Los hints necesitan un contrato propio
Una sugerencia debe ser legal en el estado actual y seguir teniendo sentido después de undo o de una ruta distinta a la guía. Puede requerir cálculo local en lugar de seguir ciegamente una secuencia precalculada.
El onboarding puede enseñar predicción
Una buena escena puede ofrecer tres colores y preguntar cuál absorberá dos componentes. Así enseña regla y frontera a la vez. El tutorial no necesita enseñar toda la estrategia, solo hacer predecible la transición de estado.
La UI debe distinguir territorio poseído de color coincidente
En tableros grandes puede haber casillas del mismo tono que aún no forman parte de la región. El diseño necesita dejar clara esa diferencia mediante borde, patrón o feedback. Si “mismo color” parece “ya conquistado”, la estrategia se vuelve ilegible.
El feedback debe explicar causalidad
Recoloración, absorción y contador deben actualizarse de forma coherente. Una animación puede ayudar a ver qué componentes entraron, siempre que respete reduced motion y no retrase el siguiente input.
Responsive convierte 24×24 en un problema de producto
Una cuadrícula cómoda en escritorio puede ser minúscula en móvil. Zoom, escalado o disponibilidad por viewport son decisiones reales. Que el motor soporte un tamaño no obliga a mostrarlo en cualquier contexto si la experiencia deja de ser usable.
Los temas necesitan paletas funcionales
Una combinación que funciona sobre fondo oscuro puede perder contraste en claro. Selección, foco, hover y finalización tienen que seguir distinguiéndose porque el color transporta estado, no decoración.
El teclado también forma parte de accesibilidad
Elegir colores debería ser posible con foco visible y orden predecible. Los atajos pueden acelerar, pero no deben ser la única forma no táctil de completar la interacción.
La taxonomía puede evolucionar sin tocar el engine
Las categorías de patrones y regiones pertenecen al descubrimiento. Podemos ajustar recomendaciones y etiquetas sin cambiar reglas si la metadata permanece fuera del algoritmo.
Cambiar la paleta no debería cambiar una seed
Los colores lógicos pueden representarse por índices y mapearse a tonos en la capa visual. Así una mejora de accesibilidad no altera la estructura generada ni rompe reproducibilidad.
El shell compartido debe quedarse fuera del algoritmo
El motor necesita componentes, movimientos y finalización. No necesita saber cómo se abre un modal, dónde se persiste un resultado o qué ruta usa la web. Mantener esa frontera facilita tests aislados.
Qué revisaría antes de marcar available
Además de self-test verde, revisaría todas las combinaciones en desktop y móvil, teclado, temas, reduced motion, restauración, Challenge, undo, onboarding y resultados. Mantendría varias seeds representativas como smoke tests visuales.
Colors demuestra por qué una plataforma rodea al motor
La regla central es pequeña frente a todo lo necesario para una experiencia consistente. El game shell absorbe responsabilidades repetidas y deja al engine concentrado en la mecánica.
La optimización futura debe conservar explicabilidad
Si usamos búsqueda más sofisticada, conviene conservar métricas entendibles: longitud de guía, cota, reintentos, tiempo y memoria. Una puntuación opaca puede mejorar un número y dificultar la depuración.
El criterio final sigue siendo sencillo
Colors estará realmente terminado cuando la persona entienda qué controla, pueda predecir el efecto de una elección, confíe en que Challenge es alcanzable y reciba el mismo nivel de calidad que en el resto de Blupoli.
La publicación debe preservar esa evidencia
No basta con cambiar coming-soon a available. El cambio debería ir acompañado de gates que prueben la experiencia integrada, para que el estado público sea una consecuencia de evidencia y no una etiqueta manual.
La dificultad puede medir libertad de maniobra
Una guía corta no significa necesariamente una partida fácil. Un tablero puede permitir muchas rutas parecidas y otro exigir una secuencia muy estrecha. Esa libertad de maniobra influye en la presión que siente el jugador. Herramientas internas pueden estimarla sobre seeds estables y usar el resultado para ajustar la generación sin trasladar una búsqueda pesada al navegador.
Las seeds de QA deberían convertirse en una biblioteca
Cuando aparece una partida especialmente buena, mala o extraña, conservar su seed crea conocimiento reutilizable. Con el tiempo podemos reunir casos de islas tardías, repeticiones forzadas, fronteras abiertas, tableros grandes y configuraciones que estresan la heurística. Esa colección ayuda a revisar cambios sin depender de que el azar vuelva a producir un caso parecido.
Los fallos de generación necesitan degradación segura
Si varios intentos no producen un candidato verificable, el producto puede cambiar de seed o cargar un fallback previamente validado. Es preferible repetir menos contenido a relajar la garantía de Challenge o dejar la interfaz esperando indefinidamente. La degradación debe preservar las propiedades que el usuario sí percibe como promesa.
Casual puede compartir motor sin compartir presupuesto
Que Casual no muestre límite no significa que deba aceptar tableros sin comprobar. Compartir generador y separar únicamente la política de sesión evita mantener dos motores que diverjan con el tiempo. La diferencia entre modos puede vivir en presentación, resultados y reglas de objetivo.
La paleta lógica debería ser independiente de la visual
Los colores pueden existir internamente como índices estables y mapearse después a tonos concretos. Así un tema accesible modifica la apariencia sin cambiar la estructura de una seed, y los tests de dominio no dependen de códigos hexadecimales. La presentación puede evolucionar sin alterar la identidad lógica del tablero.
Los tests visuales solo necesitan algunas seeds representativas
No hace falta mantener miles de screenshots. Un conjunto pequeño puede cubrir tamaños, estados intermedios, foco, finalización, temas y móvil. Las seeds hacen que esas referencias sean reproducibles entre commits. Los tests de lógica cubren variedad; los visuales cubren composición. Cada evidencia responde una pregunta distinta.
La métrica “movimiento” necesita semántica estable
Si una versión futura decide que pulsar el color actual no consume turno o cambia cómo funciona undo, los resultados históricos dejan de ser directamente comparables. Las reglas de conteo deben documentarse y versionarse cuando cambien de forma incompatible. Una estadística solo es fiable cuando sabemos que el término medido significaba lo mismo.
Challenge necesita una política clara al superar el límite
Podemos permitir continuar fuera del objetivo, marcar el intento como fallido o proponer un reintento. Cualquiera puede funcionar si se comunica antes de llegar al límite y si motor, UI y resultados interpretan el contador de la misma manera. El presupuesto no debe convertirse en una sorpresa después de varios minutos de juego.
Retry y New game deben significar cosas distintas
Retry debería conservar seed y objetivo para que el jugador pueda aprender del intento anterior. New game debería crear una seed distinta. Son etiquetas pequeñas, pero forman parte del contrato de reproducibilidad y permiten que una mejora entre intentos tenga un contexto claro.
La finalización debe ser idempotente
Cuando toda la cuadrícula pertenece a la región, eventos duplicados o trabajo asíncrono tardío no deben registrar dos resultados. El shell tiene que tratar completar como una transición única. Restaurar una partida ya completada tampoco debería volver a disparar sonidos, confeti o telemetría de finalización.
Publicar debería añadir evidencia, no retirarla
Cuando el manifiesto pase a available, los tests que hicieron fiable el motor deberían permanecer. El salto a producción aumenta la importancia de conservar garantías, no la reduce. Un catálogo grande se mantiene sano cuando cada juego llega con su propia evidencia y la conserva durante su evolución.
La variedad procedural está subordinada a la confianza
Generar muchas partidas solo aporta valor si son rápidas, reproducibles y justas. Cuando un candidato no puede verificarse dentro del presupuesto, rechazarlo es mejor que debilitar el contrato. La calidad forma parte de la generación y no debería convertirse en una fase opcional posterior.
Colors resume bien la filosofía de Blupoli
Las reglas caben en pocas frases, pero el producto completo exige contratos sobre generación, dificultad, interacción, accesibilidad, persistencia y publicación. Esa distancia entre una mecánica simple y una experiencia confiable es precisamente el tipo de problema que una plataforma compartida debe resolver.
La publicación no termina el trabajo
Cuando Colors salga de coming-soon, la calidad tendrá que seguir midiéndose con cada cambio. Nuevas paletas, ajustes de dificultad, mejoras de rendimiento o integración con estadísticas pueden romper contratos que hoy están verdes. Mantener seeds de regresión, self-tests y casos visuales convierte la publicación en el comienzo de una etapa mantenible, no en el punto en el que dejamos de comprobar.
Ese es el objetivo real de esta arquitectura: que el juego pueda evolucionar sin volver a depender de intuición y pruebas manuales cada vez que tocamos una pieza compartida.