nota técnica
Un puzzle que no se puede buscar
El fondo de este sitio es navegable. Hay un elevador y una bóveda con una puerta acorazada cerrada. En la mesa del taller, hay una pequeña caja metalica; el disco de la puerta abre un teclado de cuatro posiciones.
Es opcional y no bloquea nada: todas las secciones siguen a un clic desde el dock. Aun así fue divertido imeplementar.
Lo primero fue descartar el puzzle obvio
La idea evidente era contar objetos del fondo: cuántas pantallas, cuántos logos, cuántas lámparas. No funciona, por dos motivos distintos.
El primero es de implementación: la imagen se recorta para cubrir la pantalla, así que en ventanas estrechas los objetos de los bordes sencillamente no están. El puzzle sería irresoluble según el ancho del navegador.
El segundo es peor. «Cuántos logos hay» es ambiguo. Alguien cuenta el del suelo y alguien no cuenta el que está medio tapado, y los dos tienen razón. Un puzzle donde puedes acertar y recibir un error no es difícil: está roto, con la dificultad puesta de disfraz.
La combinación se genera, no se guarda
Cuatro dígitos, nuevos en cada carga de la página. No hay ningún número fijo en el código ni en el HTML.
- la respuesta no se puede compartir ni buscar en internet;
- hay que leer la cinta de verdad;
- recargar da un puzzle nuevo, así que se puede volver a jugar.
Buscar un secreto en el código fuente es el primer reflejo de cualquiera que sepa
abrir el inspector. Si el premio está ahí escrito, el puzzle dura lo que tarda en
pulsar Ctrl+U.
La leyenda está en la mesa
La cinta tiene cuatro columnas con las cabeceras 8 4 2 1 y cuatro
filas, una por dígito. Se suman las columnas marcadas.
8 4 2 1
1ª ○ ● ○ ○ = 4
2ª ● ○ ○ ● = 9Las cabeceras son la clave del diseño. Con ellas, quien juega no necesita saber qué es el binario: suma lo que ve. Sin ellas, el puzzle deja de medir observación y pasa a medir si estudiaste sistemas numéricos. Esa es la diferencia entre un puzzle y un examen.
Los dígitos se limitan a 0–9 aunque cuatro columnas llegarían hasta 15, porque la cerradura solo tiene diez teclas. Generar un 13 que no se puede introducir habría sido cruel.
Un puzzle visual que también se resuelve sin ver
Los símbolos ● y ○ no se anuncian de forma fiable en un
lector de pantalla. Tal cual, el puzzle sería imposible sin vista.
La cinta está marcada como una tabla de verdad:
- encabezados de columna y de fila declarados como tales;
- el glifo oculto para tecnologías de asistencia;
- y al lado, invisible en pantalla, el texto perforado o liso.
La cerradura acepta teclado además de clic: dígitos, borrar y aceptar. Con un detalle que solo aparece al probarlo: si el foco está sobre un botón, manda la activación nativa del botón. Sin eso, pulsar enter encima de borrar enviaría la combinación en lugar de borrarla.
Lo que se puede probar sin navegador
El módulo que genera la combinación y la codifica en filas es puro: no toca el DOM, no lee la página, no depende de nada del navegador. Recibe datos y devuelve datos.
Por eso se prueba con el runner de pruebas que ya trae la plataforma, sin navegador y sin DOM falso. Las pruebas comprueban lo que de verdad puede romperse:
- que nunca se genere un dígito sin tecla en la cerradura;
- que cada dígito sobreviva la ida y la vuelta de la codificación;
- que una fila leída de la cinta sume exactamente su dígito;
- que solo la combinación exacta abra la puerta.
Que esas pruebas sean fáciles no fue suerte: es la consecuencia de haber separado la lógica del dibujo. La parte que se puede probar barato es la que se decidió que no supiera nada de la pantalla.
El estado dura lo que dura la visita
Al recargar, la bóveda vuelve a estar cerrada y la combinación cambia. No se guarda nada, a propósito: no hay recompensa material que proteger, y persistirlo habría añadido almacenamiento a cambio de nada.
Decidir qué no guardar es parte del trabajo. Todo dato que se guarda hay que migrarlo, respaldarlo y, si es de una persona, protegerlo y borrarlo cuando toque.
Por qué esto no es solo para juegos
Las tres decisiones se repiten iguales en trabajo que alguien paga:
- ser generoso con lo que cuenta como correcto, en vez de castigar al usuario por una ambigüedad que pusimos nosotros;
- separar la lógica de la pantalla, porque es lo que hace que exista una prueba;
- que una funcionalidad sea accesible desde el principio, y no un arreglo posterior que casi siempre no llega.
La puerta está en la bóveda. La combinación cambia cada vez, así que no podemos dártela ni aunque quisiéramos.