Las ecuaciones se cruzan como palabras
Qué es Math Crossword
El tablero alterna casillas numéricas y operadores. Filas y columnas forman ecuaciones que se cruzan en los números, igual que dos palabras comparten letras. El jugador recibe parte de los valores y deduce los restantes para que todas las igualdades sean correctas a la vez.
La gracia está en la intersección. Resolver una ecuación horizontal puede fijar un número que desbloquea otra vertical; esa segunda devuelve información a otra fila. El puzzle es una red de restricciones aritméticas.
De los crossnumbers a las ecuaciones cruzadas
Los puzzles numéricos en formato de crucigrama tienen una historia larga. Se suele citar a Henry Ernest Dudeney por uno de los primeros crossnumber conocidos, publicado en 1926. Aquellos puzzles normalmente sustituían palabras por respuestas numéricas a pistas.
Math Crossword comparte la idea de cruzar información numérica, pero las relaciones aquí están escritas como operaciones dentro del propio tablero. Preferimos describirlo como una variante moderna inspirada en esa familia, no como reproducción histórica directa.
El cruce es más importante que la operación: un número vale porque debe satisfacer dos contextos a la vez.
Paridad con Android
La aplicación Android define cuatro tamaños canónicos: 5×5, 7×7, 9×9 y 11×11, además de cuatro dificultades. La web mantiene esa matriz completa.
Esta migración ayudó a establecer una regla de proyecto: los juegos canónicos de Android deberían tener representación web salvo excepción temporal documentada.
Portar la idea, no el código
Paridad funcional no significa que ambas plataformas tengan que compartir implementación. El navegador tiene restricciones y herramientas diferentes, así que el motor JavaScript se diseñó para producir la misma experiencia conceptual dentro de la arquitectura web.
Eso nos permite comparar enfoques y, al mismo tiempo, mantener una identidad de juego coherente.
Cómo genera el tablero la versión web
El motor construye una malla de valores numéricos y deriva ecuaciones horizontales y verticales compatibles. Después retira cifras para crear huecos. La dificultad modifica rango de números, operaciones y proporción de casillas ocultas.
Las ecuaciones comparten números reales, no pistas independientes superpuestas. Modificar un cruce afecta a fila y columna simultáneamente.
Por qué usamos propagación lógica
Antes de aceptar un tablero, un solver intenta reconstruir los números retirados. Si en una ecuación queda un único valor desconocido, puede despejarse directamente; ese resultado alimenta el resto. Repetimos hasta completar o demostrar que la configuración no queda suficientemente determinada.
El selfTest() genera y resuelve las combinaciones de tamaño y dificultad para evitar que una modificación convierta un modo en imposible.
- ecuaciones aritméticamente correctas;
- cruces globalmente coherentes;
- suficiente información para propagar;
- diferencias medibles entre dificultades;
- resolución dentro de un coste razonable.
La dificultad no debería ser solo números más grandes
Aumentar el rango puede añadir carga de cálculo, pero no necesariamente deducción. También importa cuántos huecos hay, qué operaciones aparecen y cuántas ecuaciones se desbloquean entre sí.
El objetivo es que Experto exija navegar mejor la red de restricciones, no simplemente hacer cuentas más incómodas.
Consejos para jugar
Busca ecuaciones con un solo hueco: son pistas directas. Después prioriza números situados en cruces, porque una deducción puede resolver simultáneamente parte de una fila y una columna.
En tableros mayores no intentes completar una ecuación larga de principio a fin. Trabajar desde cruces restringidos reduce antes el espacio de posibilidades.
La interfaz debe distinguir datos y operadores
Un tablero aritmético puede volverse denso rápidamente. Números editables, valores dados, operadores y signos de igualdad necesitan jerarquías visuales distintas para que el jugador reconozca de inmediato dónde puede actuar.
Es otra mecánica que se beneficia del shell común pero necesita un tablero con personalidad propia.
Juegos parecidos
Prueba Kakuro, KenKen, Killer Sudoku o Suko. Todos usan números, pero distribuyen las restricciones de maneras diferentes.
Fuentes y contexto histórico
La referencia histórica a Dudeney procede de la bibliografía de puzzles recreativos que identifica un crossnumber suyo en 1926. La referencia funcional principal es Math Crossword de Blupoli Android.
Henry E. Dudeney — Modern Puzzles and How to Solve Them (1926)
Estado actual: motor real, publicación pendiente
Math Crossword tiene un engine nativo en el repositorio y una matriz explícita de tamaños y dificultades, pero su manifiesto actual sigue en coming-soon. Esta entrada puede describir la implementación y las garantías que verificamos, no presentar el juego como una experiencia pública ya terminada.
La diferencia es importante: portar la idea desde Android, construir un generador y pasar self-tests son hitos técnicos. Publicar exige además onboarding, responsive, accesibilidad, persistencia y resultados comunes.
El tablero es una red de ecuaciones, no una lista de cuentas
Cada número puede participar en una ecuación horizontal y otra vertical. Esa intersección es la fuente principal de deducción: resolver un hueco cambia dos contextos a la vez. El puzzle funciona mejor cuando pensamos en una red de restricciones que comparte variables, no en operaciones independientes colocadas dentro de una cuadrícula.
Por eso una cifra aparentemente local puede desbloquear varias ramas de propagación.
Los cuatro tamaños son 5×5, 7×7, 9×9 y 11×11
El engine define esos cuatro tamaños canónicos. La estructura alterna números y operadores, así que crecer dos unidades añade nuevas variables y nuevas intersecciones sin romper el patrón. El tamaño afecta a duración y densidad de la red; la dificultad se controla por otros parámetros.
La dificultad cambia rango, restas y proporción de huecos
Fácil usa números pequeños, una probabilidad muy baja de resta y menos casillas ocultas. Normal amplía rango y huecos. Difícil y Experto aumentan ambas dimensiones hasta llegar a números de dos cifras, más restas y una proporción mayor de valores retirados.
Esto es mejor que ligar dificultad únicamente al tamaño, porque permite un tablero amplio pero accesible o uno compacto con una red más exigente.
El generador parte de una matriz completa coherente
Primero construye los valores numéricos y las relaciones que darán lugar a ecuaciones horizontales y verticales. Después deriva operadores compatibles y, finalmente, retira valores para crear el puzzle. La solución existe antes que los huecos.
Ese orden permite verificar cada ecuación contra una misma asignación global y evita ensamblar pistas independientes que luego se contradigan en los cruces.
Retirar números no puede destruir la propagación
El proceso de ocultación no se limita a alcanzar una cuota de huecos. El motor intenta resolver por propagación y revierte retiradas que impiden reconstruir la solución esperada. La generación usa al solver como filtro de calidad.
La idea conecta con generar no es resolver: el candidato y la evidencia de que ese candidato funciona son responsabilidades diferentes.
La propagación aprovecha ecuaciones con una incógnita
Cuando una ecuación conserva todos sus valores salvo uno, el engine puede despejar el hueco. Ese resultado se inserta en la matriz y quizá deje otra ecuación con una sola incógnita. Repetir este proceso convierte los cruces en una cadena de consecuencias.
La técnica es simple, pero encaja muy bien con el objetivo del puzzle: queremos que el tablero se vaya abriendo mediante información compartida.
El self-test recorre tamaño y dificultad
Para cada combinación, genera una partida, ejecuta propagación y exige que la solución reconstruida coincida con la solución original. También verifica que todas las ecuaciones sean válidas y que exista al menos una celda editable.
Es una comprobación estrechamente ligada a lo que la UI promete: cada opción debe producir un puzzle que el motor pueda resolver según su propio contrato.
El solver actual demuestra una ruta lógica concreta
Que propagación recupere la solución es una garantía útil, pero no debemos convertirla en una afirmación más amplia de lo que es. El engine comprueba que su proceso puede reconstruir el tablero; no está demostrando todavía un catálogo completo de técnicas humanas ni asignando dificultad pedagógica.
Solución conocida y unicidad son preguntas distintas
Una matriz completa demuestra que existe una respuesta. Para afirmar unicidad necesitaríamos contar soluciones alternativas bajo todas las restricciones. El self-test actual se centra en que la propagación recupere la asignación generada.
Mientras el juego siga en coming-soon, esta frontera es precisamente el tipo de propiedad que debemos revisar antes de publicar lenguaje demasiado fuerte sobre “solución única”.
El artículo histórico hablaba de paridad con Android
La idea de Math Crossword viene de la experiencia Android de ArceApps, pero la implementación web es JavaScript nativo dentro de la arquitectura de Blupoli. Paridad funcional no significa compartir código línea por línea.
El valor está en preservar identidad —tamaños, lógica de ecuaciones, niveles— y adaptar el motor a las necesidades del navegador y del shell común.
Portar conceptos es más sostenible que portar acoplamientos
Un engine web no debería cargar decisiones específicas de una Activity, ViewModel o almacenamiento Android. Conviene identificar dominio, estado serializable y contratos de interacción, y reconstruir esas piezas con herramientas nativas de la plataforma destino.
Así las dos versiones pueden evolucionar sin que cada ajuste de UI obligue a mantener una capa artificial de compatibilidad.
Las ecuaciones necesitan una semántica inequívoca
Operadores, precedencia y dirección deben ser claros. El engine actual construye relaciones lineales controladas, lo que simplifica el cálculo y la propagación. Si en el futuro añadimos multiplicación o divisiones más complejas, tendremos que decidir explícitamente cómo se evalúan y qué valores intermedios son legales.
Evitar resultados fraccionarios es parte de la generación
Para un puzzle de números enteros, una operación que obligue a introducir decimales inesperados rompería la expectativa. El generador valida que los despejes produzcan enteros dentro del rango permitido. El contrato aritmético forma parte del dominio, no solo del render.
La dificultad no debería ser “hacer cuentas más incómodas”
Aumentar el valor máximo añade carga aritmética, pero la profundidad interesante está en cuántas ecuaciones se desbloquean, cuánto tarda en aparecer una incógnita directa y qué cruces concentran información.
Una calibración futura puede medir pasos de propagación, tamaño de cadenas y número de estados en los que no existe una deducción inmediata.
Los huecos importan por su posición
Ocultar dos números en ecuaciones que se cruzan puede crear más dependencia que ocultar cuatro valores dispersos. Por tanto, la proporción de huecos es solo una señal gruesa. El patrón de dónde están retirados determina buena parte de la experiencia.
Un benchmark útil debe conservar seeds y estructura
Si cambiamos holeRatio, rangos o heurísticas de ocultación, deberíamos comparar sobre casos reproducibles. Seeds estables permiten observar si el nuevo generador mantiene tiempos, propagación y densidad de deducciones similares.
La latencia debe mantenerse predecible
En tamaños 11×11 hay más variables y ecuaciones. Aunque la propagación sea barata, la generación puede hacer varios intentos de ocultación. Los tests deberían vigilar no solo promedio, sino peores casos, porque una partida que tarda varios segundos en aparecer puede hacer que el producto parezca roto.
La cancelación importa si la generación crece
Si el jugador cambia tamaño mientras se genera, el resultado anterior no debería sobrescribir la selección nueva. Un futuro worker o proceso asíncrono necesita versionar solicitudes y descartar respuestas obsoletas.
La UI necesita separar dato fijo, dato editable y operador
En una cuadrícula densa, el jugador debe reconocer al instante qué cifras son pistas, cuáles puede modificar y qué símbolos son estructura. Color por sí solo no debería cargar toda la diferencia; peso, fondo, borde y foco pueden colaborar.
El teclado es especialmente natural en este puzzle
Introducir números con teclado reduce fricción. Aun así, el orden de foco, borrar, cambiar casilla y navegación con flechas tienen que ser consistentes. La accesibilidad no debe depender de memorizar atajos no visibles.
Los errores pueden detectarse sin revelar toda la solución
La UI puede marcar que una ecuación completa es inválida sin señalar inmediatamente cuál número es correcto. Eso ofrece feedback local y mantiene la deducción en manos del jugador.
Una política de errores demasiado agresiva convertiría el tablero en un corrector automático y reduciría la necesidad de cruzar información.
Los hints deberían explicar qué ecuación está lista
En lugar de insertar un número, una pista puede señalar una fila o columna que ya tiene una sola incógnita. Es una ayuda alineada con la técnica que el solver realmente usa y enseña cómo avanzar.
Un hint más avanzado puede explicar la propagación
Podemos mostrar que resolver una ecuación entrega un valor compartido con otra. Ese vínculo es el corazón del puzzle y una buena oportunidad pedagógica: la persona aprende por qué el cruce importa, no solo qué número escribir.
El onboarding debería empezar con un cruce pequeño
Una mini escena 5×5 puede mostrar una ecuación horizontal con un hueco y cómo el valor obtenido aparece también en una vertical. Enseñar esa transferencia vale más que recorrer todos los controles de la pantalla.
Persistir el tablero requiere distinguir solución y progreso
Un save necesita configuración, seed o estado generado, valores dados y entradas del jugador. La solución puede permanecer interna y no debería confundirse con el progreso guardado. Esta separación ayuda a evitar filtraciones accidentales hacia la UI.
Los resultados comunes deberían incluir tamaño y dificultad
Una partida 5×5 Fácil no es comparable directamente con 11×11 Experto. Duración, errores, ayudas y quizá pasos de deducción solo tienen sentido con contexto. La plataforma debe guardar suficiente metadata para interpretar la sesión.
El modo coming-soon evita prometer antes de tiempo
Que el engine ya tenga generación y tests es una buena base, pero todavía podemos revisar unicidad, UX móvil, localización, onboarding y persistencia antes de convertirlo en available. La etiqueta no resta valor al progreso; describe honestamente el trabajo restante.
El siguiente gate debería revisar ambigüedad
Antes de publicación, una mejora razonable es contar soluciones o demostrar una propiedad equivalente adecuada al modelo. Si el objetivo de producto es una respuesta única, esa garantía debe existir en código y tests antes de aparecer en copy.
Las fuentes históricas necesitan precisión
Los crossnumbers tienen una historia anterior a Blupoli y existen múltiples formatos. Es razonable situar Math Crossword dentro de esa tradición de puzzles numéricos cruzados, pero no afirmar que nuestra estructura concreta sea reproducción directa de un diseño histórico específico.
Cuando una referencia histórica no cambia cómo se juega, preferimos formulación cauta y fuente explícita.
La relación con otros puzzles numéricos es estructural
Kakuro comparte sumas y cruces; KenKen utiliza jaulas; Killer Sudoku combina restricciones latinas y aritmética. Math Crossword se distingue porque las operaciones están escritas en una red de ecuaciones que comparte variables.
La taxonomía debería describir aritmética relacional
El juego pide despejar, propagar y combinar información entre ecuaciones. Podemos describir esas acciones sin prometer beneficios cognitivos. Esa precisión sigue el enfoque de la taxonomía de Blupoli.
Los visuales de este artículo modelan el cruce
La portada y la infografía no intentan reproducir una partida completa. Representan dos ecuaciones que se cruzan y la dirección de propagación. Es una relación más útil para entender el engine que una captura decorativa.
Qué significa terminar Math Crossword
El motor debe generar rápido, mantener la semántica aritmética, producir dificultad coherente y pasar sus tests. El producto además necesita onboarding, responsive, teclado, accesibilidad, persistencia, resultados y una garantía explícita sobre ambigüedad si la prometemos.
La lección principal es compartir variables de verdad
Math Crossword funciona cuando el cruce no es visual sino lógico: el mismo número pertenece a dos ecuaciones y transporta información de una a otra. La implementación, la UI y el tutorial deberían proteger siempre esa idea central.
Contar soluciones debería formar parte del cierre de producto
La propagación actual demuestra que la solución generada se recupera mediante una ruta lógica concreta, pero una promesa pública de “solución única” merece una prueba diferente. Un contador con corte en dos permitiría distinguir imposible, única y múltiple sin enumerar todas las respuestas. Ese gate sería especialmente valioso antes de retirar coming-soon.
La ambigüedad puede esconderse detrás de una propagación exitosa
Que el solver encuentre la asignación original no excluye automáticamente otra combinación válida que requiera elecciones distintas. El generador y el verificador deben responder preguntas separadas. La solución construida es un testigo de existencia; el contador de soluciones es la evidencia de unicidad.
Las ecuaciones completas pueden actuar como unidades de validación
Mientras el jugador escribe, no hace falta comparar cada celda con la solución oculta. Cuando una ecuación queda completa podemos comprobar si satisface su igualdad. Ese feedback utiliza reglas visibles y evita revelar información que el propio tablero todavía no justifica.
La dificultad puede registrar cuándo aparecen bloqueos
Un tablero donde siempre existe una ecuación con una sola incógnita ofrece un flujo muy distinto de otro que alterna cadenas largas y momentos de búsqueda. Instrumentar el solver para registrar cuántas deducciones directas hay en cada estado puede producir un perfil más expresivo que el porcentaje de huecos.
Los resultados deberían conservar ayudas y auto-check como contexto
Si dos sesiones usan políticas de feedback distintas, su duración y errores no son estrictamente comparables. Guardar si había auto-check, cuántos hints se pidieron y qué tamaño/dificultad se jugó aporta contexto sin convertir esas señales en una puntuación moral.
La internacionalización también afecta a instrucciones matemáticas
Los símbolos son compartidos, pero expresiones como “despeja”, “incógnita” o “ecuación completa” necesitan traducciones consistentes. Un glosario por mecánica puede evitar que tutorial, reglas y hints usen vocabulario distinto para la misma operación.
Un test de round-trip protege la persistencia
Serializar y volver a cargar una partida debería conservar pistas, entradas, tamaño, dificultad y estado de finalización. Después del round-trip, las mismas ecuaciones completas deben seguir validando de la misma manera. El dominio, no solo el JSON, tiene que sobrevivir.
El estado visual debe derivarse del dominio
Casillas erróneas, seleccionadas o resueltas no deberían guardarse como clases CSS permanentes. Al cargar, la UI puede reconstruir esos estados a partir de valores y reglas. Reducir información duplicada evita saves imposibles de migrar.
Un worker futuro necesitaría mensajes pequeños
Si generación o conteo de soluciones salen del hilo principal, conviene enviar matrices compactas y parámetros en lugar de clonar estructuras de UI. El contrato con el worker debe seguir hablando en términos del puzzle, no de nodos DOM.
La publicación debería exigir la misma evidencia en todas las configuraciones
No bastará con demostrar unicidad en 5×5 Fácil si 11×11 Experto usa parámetros distintos. Tamaño y dificultad son opciones públicas; cualquier propiedad prometida debe probarse sobre la matriz completa o sobre una estrategia de muestreo documentada que garantice cobertura suficiente.
Math Crossword merece ser difícil por relaciones, no por fatiga aritmética
El objetivo de Experto no debería ser obligar a multiplicar números enormes mentalmente. La dificultad más interesante aparece cuando una deducción viaja por varios cruces y obliga a elegir dónde empezar. La calibración futura debería premiar esa estructura.
El criterio de publicación puede resumirse en una pregunta
¿Puede una persona confiar en que cada hueco pertenece a una red coherente, que el tablero tiene la propiedad de solución que prometemos y que cualquier opción visible funciona en móvil, teclado y persistencia? Cuando la respuesta sea sí con tests detrás, available tendrá un significado real.