La clienta y su paleta de acuarela

Algunos proyectos llegan con una identidad visual ya bien formada, y este era uno de ellos. Mi clienta tiene buen ojo, personalidad clara y gustos muy definidos. Llegó con su logotipo bajo el brazo y una paleta cromática que lo decía todo sobre ella: tierra, crema, verde salvia, un terracota casi imperceptible. Colores suaves como una mañana de domingo. Nada estridentes, nada agresivos. Una estética coherente y honesta que, desde el punto de vista puramente visual, tiene todo el sentido del mundo.

Su idea para la web era clara: fondo blanco, textos en gris suave —porque el negro le resultaba demasiado agresivo—, acentos en crema y esas pinceladas de verde y terracota que definen su marca. Una página tranquila, sin ruido, que transmitiera exactamente lo que ella quería transmitir.

Y desde el punto de vista estético, ¿quién soy yo para llevarle la contraria?

El gusto es el gusto, y no hay vuelta de hoja

Podría pensar —y lo pienso— que una paleta tan desaturada corre el riesgo de resultar sosa. Que le falta tensión visual, que los elementos importantes se pierden, que el ojo del usuario no sabe muy bien dónde mirar. Pero eso es mi opinión, y mi opinión no paga la factura ni toma las decisiones.

El gusto personal no se discute. Podemos educar, podemos proponer, podemos mostrar alternativas. Pero si una clienta llega con una identidad consolidada que le funciona, que le representa y que le gusta, nuestra labor no es convencerla de que se equivoca, sino entender qué necesita y ayudarla a trasladarlo al entorno digital de la mejor manera posible.

El problema, claro, es que a veces lo que nos llega tiene que pasar por ciertos filtros antes de llegar a la pantalla del usuario final. Y uno de esos filtros, en 2026, ya no es opcional.

La accesibilidad web no es una opinión

Aquí es donde la conversación se complica. Porque lo que hasta hace poco era una recomendación —las pautas WCAG de accesibilidad web— ha pasado a ser una obligación legal en Europa a través de la European Accessibility Act (EAA), cuya aplicación efectiva llegó en 2025.

Y las WCAG tienen algo muy claro que decir sobre el color: el contraste entre texto y fondo debe superar una ratio de 4,5:1 para texto normal y de 3:1 para texto grande. Esto no es una preferencia estética. Es un número. Un número que se puede medir, calcular y verificar con herramientas en cuestión de segundos.

Cuando coges esa paleta tan delicada —el gris clarito sobre blanco, el verde suave sobre crema, el terracota ligerísimo sobre cualquier cosa— y la metes en un comprobador de contraste, el resultado es siempre el mismo: fail, fail, fail. El gris que no quería perturbar perturba precisamente a quienes más necesitan que los textos sean legibles: personas con baja visión, usuarios mayores, quienes leen en condiciones de iluminación adversas. La delicadeza visual se convierte, sin quererlo, en una barrera de acceso.

La conversación que nadie quiere tener

Explicar esto a alguien que no quiere tocar su paleta es uno de los momentos más delicados de este trabajo. No se trata de decirle que sus colores son feos —que no lo son— ni de que su criterio estético está equivocado —que no lo está—. Se trata de explicarle que hay una normativa que protege a una parte de los usuarios, y que ignorarla no es una opción que esté sobre la mesa.

La reacción más habitual es la resistencia. "Pero es que así no parece mi marca." "Si oscurezco el texto pierde la sutileza." "Es que el negro sobre blanco es muy agresivo." Y uno entiende esas reacciones, porque vienen de un lugar genuino. Nadie quiere que le digan que lo que ha construido con tanto cuidado tiene un problema.

La clave está en no presentarlo como una crítica al gusto ajeno, sino como una restricción técnica y legal, del mismo tipo que las que aplican al etiquetado de productos o a la señalización de emergencias. La ley no opina sobre la estética de una señal de salida de incendios, pero sí exige que sea visible. En la web pasa exactamente lo mismo, y el argumento suele aterrizar mejor cuando se plantea así: no es que sus colores estén mal, es que la norma no distingue entre bonito y funcional.

Compromisos que no deberían serlo

La buena noticia es que casi siempre existe margen de maniobra. El truco está en encontrar versiones de los colores elegidos que, con ajustes mínimos de luminosidad o saturación, pasen el umbral de contraste sin traicionar el espíritu de la paleta original.

Un terracota algo más intenso, pero todavía cálido. Un verde un poco más oscuro, que siga siendo vegetal y tranquilo. Un gris de texto que, en lugar de rozar el blanco, se sitúe en una zona que garantice legibilidad sin necesidad de llegar al negro puro. Son cambios que muchas veces resultan imperceptibles para quien no tiene el ojo entrenado, pero que marcan la diferencia entre una web accesible y una que incumple la normativa.

La clave es trabajar con la clienta en esos ajustes, no imponérselos. Mostrarle los dos colores juntos, explicarle qué cambia y qué no. A veces, cuando ve que el verde "accesible" sigue siendo verde —solo un par de puntos más oscuro en la escala HSL—, la resistencia se diluye. Otras veces hay que llegar a acuerdos más estructurados: reservar los colores delicados para elementos puramente decorativos —ilustraciones, fondos de sección, separadores— y usar las versiones con mayor contraste solo donde hay texto. Es más trabajo, pero es una solución honesta para ambas partes.

Lo que nos toca a nosotros

Al final, la accesibilidad web no es un extra que se añade si al cliente le apetece. Es parte de lo que significa hacer bien nuestro trabajo. Y eso incluye la parte incómoda: decirle a alguien, con toda la delicadeza del mundo, que hay algo en su propuesta que necesita ajustarse.

No es un juicio sobre el gusto ajeno. Es una responsabilidad compartida. La nuestra, como profesionales, es conocer la normativa y aplicarla. La del cliente, como propietario de un sitio web, es tener un espacio que no excluya a nadie.

Ese verde tan suave puede seguir siendo suyo. Solo necesita ser, también, de todos.

El hombre que hizo más portadas que Rockwell

Leyendecker nació en Alemania en 1874 y emigró a Estados Unidos de niño. Se formó en Chicago y París, y a principios del siglo XX ya era el ilustrador comercial más solicitado del país. Hizo más de cuatrocientas portadas del Saturday Evening Post, la revista de mayor tirada de América en aquella época. Más que Norman Rockwell, que vivía cerca de él en parte precisamente para aprender de su trabajo y que reconoció abiertamente su influencia.

También fue Leyendecker quien fijó visualmente algunas de las imágenes más arraigadas en el imaginario americano: el bebé que representa el año nuevo sustituyendo al anciano del año anterior, las escenas navideñas, las estampas de Acción de Gracias. Imágenes que han sido reproducidas y reinterpretadas tantas veces que ya nadie recuerda quién las inventó. Esa es una forma peculiar de inmortalidad — que tu obra sobreviva completamente desvinculada de tu nombre.

El Arrow Collar Man y el amor escondido en plain sight

La campaña que lo hizo más famoso en su época fue la del Arrow Collar Man, una serie de ilustraciones publicitarias para una marca de camisas que se convirtieron en fenómeno cultural. El personaje — apuesto, elegante, con esa mandíbula perfecta y esa postura de quien sabe exactamente dónde está — generó una respuesta que hoy llamaríamos viral. Las mujeres americanas enviaban cartas de amor a un hombre de papel. La empresa recibía más correspondencia dirigida al Arrow Collar Man que muchos actores de carne y hueso.

Lo que el público no sabía, y que tardó décadas en documentarse, es que el modelo era Charles Beach, la pareja de Leyendecker durante casi cincuenta años. Vivían juntos, viajaban juntos, Beach gestionaba su carrera y sus finanzas. En la América de principios del siglo XX eso era un secreto a voces que nadie nombraba en voz alta. Leyendecker llevó su vida entera escondida en plain sight: el hombre al que amaba era literalmente la cara más reconocida de la publicidad americana, y nadie hacía la pregunta obvia.

Cuando ves las ilustraciones del Arrow Collar Man sabiendo esto, algo cambia en la forma de mirarlas. Hay una calidad en cómo están dibujados esos hombres — una atención, una admiración contenida en cada trazo — que va más allá del encargo comercial.

Lo que te para los pies

Pero lo que más me llamó la atención al descubrir su obra no fue el subtexto biográfico sino algo más inmediato: la elegancia. No en el sentido de la ropa o los escenarios, aunque ambos la tienen, sino en algo más difícil de definir — las posturas corporales, la forma en que los cuerpos ocupan el espacio, la seguridad del trazo.

Los personajes de Leyendecker tienen una calidad escultórica que hace pensar más en una estatua bien iluminada que en una ilustración comercial. Los hombros, los giros de cabeza, el peso de un cuerpo apoyado en algo — todo tiene una presencia física que es inusual en el trabajo de encargo. La pincelada es suelta pero precisa, con esa paradoja técnica de los grandes dibujantes que consiguen que algo muy trabajado parezca fácil.

Es un estilo totalmente distinto al de Tom of Finland, con quien comparte sin embargo esa misma cualidad de ser inconfundible desde el primer vistazo. Donde Laaksonen era línea pura, contraste radical, exageración deliberada, Leyendecker es pintura, volumen, luz cálida, contención. Dos formas completamente distintas de mirar al cuerpo masculino, dos lenguajes visuales sin ningún punto de contacto formal, y los dos igual de marcados.

El eclipse y la reivindicación tardía

Murió en 1951 en circunstancias económicas muy distintas a las de su apogeo. Charles Beach había muerto unos años antes, y sin él Leyendecker perdió buena parte de su capacidad de gestionar una carrera que ya llevaba tiempo en declive. Rockwell, que le debía tanto, se había convertido en el nombre que todo el mundo conocía. Leyendecker quedó en un segundo plano del que tardó décadas en salir.

La reivindicación llegó despacio, impulsada en parte por el interés en recuperar la historia gay oculta en la cultura americana del siglo XX. Sus obras están ahora en colecciones importantes, su influencia se estudia, y el Arrow Collar Man ha pasado de anuncio de camisas a objeto de análisis cultural. Es el tipo de justicia póstuma que llega demasiado tarde para el interesado pero que al menos corrige el registro.

Lo descubrí hace poco, y la obra aguanta perfectamente el tiempo y la distancia. Eso es lo que importa de un artista — que cuando por fin lo encuentras, no te decepcione.

Las ilustraciones reproducidas en este artículo son obra de J.C. Leyendecker (1874–1951).

He perdido la cuenta de las veces que ha pasado. Diseño una maquetación con una cabecera cinematográfica, proporciones 16:9 o incluso 21:9, esa franja ancha y baja que en pantalla tiene una presencia brutal. El cliente la aprueba. Le gusta. Le parece perfecta. Y entonces le pido la foto para esa cabecera y me llega un retrato vertical, con el sujeto centrado en un formato que mide más de alto que de ancho.

El problema, explicado como si hubiera que explicarlo

Una imagen horizontal necesita ser ancha y poco alta. Una imagen vertical es exactamente lo contrario. No son intercambiables, del mismo modo que una bufanda no es un cinturón aunque estén hechos del mismo tejido. Si quiero rellenar un espacio horizontal con una foto vertical, solo tengo dos opciones: añado franjas a los lados para completar el ancho que falta, o recorto la imagen hasta quedarme con el fragmento que sí encaja en el espacio disponible.

No hay tercera opción. Es geometría, no una decisión de diseño. El espacio tiene unas proporciones. La imagen tiene otras. Si no coinciden, algo tiene que ceder.

La patinadora y sus tres versiones

Hubo una vez una patinadora. El cliente tenía una escuela de patinaje sobre hielo y me mandó una foto magnífica de una de sus alumnas: vertical, bien iluminada, la chica en plena pirouette con los brazos extendidos y los patines brillando. Una foto preciosa. Completamente inútil para mi cabecera panorámica.

Hice lo que me parecía más lógico: recorté por el centro, me quedé con el torso y la cara, que era donde estaba la expresión, la energía, el momento. Presenté la propuesta. El cliente la miró y me dijo que lo importante era que se viera que era una patinadora, y que con ese recorte no quedaba claro. Argumento válido, no voy a negarlo. Me pidió que se vieran los patines.

Así que rehíce el recorte por el otro extremo. Patines, tobilleras, el arranque de las piernas, el suelo de hielo. Quedaba raro, sí, una cabecera de web que empezaba en las rodillas y terminaba en el suelo, sin cara, sin contexto, con un protagonismo inesperado del calzado. Presenté la propuesta. Al cliente no le gustó. Y entonces llegó la pregunta que ya sabía que iba a llegar: ¿y no se puede ver la patinadora entera?

No. No se puede ver la patinadora entera. Porque la patinadora entera no cabe.

Lo que hoy haría en diez minutos

El remate irónico de aquella historia es que hoy ese problema tiene solución, o al menos una salida razonablemente digna. Cualquier herramienta de generación de imagen con capacidad de outpainting —extender una foto más allá de sus bordes originales— podría rellenar los laterales de esa imagen vertical con hielo generado, con pista de fondo, con ambiente de pabellón. No sería perfecto, pero sería creíble. La patinadora entera cabría en la cabecera.

Hace cinco años eso era ciencia ficción. En aquel momento la única opción era buscar otra foto, convencer al cliente de un encuadre diferente, o rendirse y poner franjas. Hoy tenemos IA generativa que rellena los huecos que la física no permite. Lo cual es fascinante y un poco perturbador a partes iguales, porque significa que el problema que intento explicar desde hace años —que una foto vertical no puede cubrir un espacio horizontal sin perder información— está a punto de dejar de ser un problema técnico para convertirse en una decisión estética. Y no sé si eso me alegra o me entristece un poco.

Mi propio tarro de mermelada

Lo que me fascina, y llevo años intentando entenderlo, es que la incapacidad del cliente no es un problema de vocabulario. No es que no sepa qué es una relación de aspecto. Es que no consigue ver la incompatibilidad. Se sienta delante de una pantalla apaisada, mira una foto en retrato, y su cerebro no activa ninguna alarma. No hay colisión cognitiva. Para él, una foto es una foto y debería poder ir donde le digas que vaya.

Me pregunto si existe algún término en psicología para eso. Alguna variante de ceguera espacial aplicada a proporciones en pantalla. Porque la habilidad que falta es muy concreta: la misma que usas cuando intentas aparcar en un hueco y calibras si tu coche cabe o no cabe. La mayoría de la gente lo hace de forma automática. Pero trasladada a imágenes, esa automatización desaparece en un porcentaje de personas que, en mi experiencia, es más elevado de lo razonablemente esperable.

Y entonces, justo cuando estoy más enrocado en mi incomprensión ante la incomprensión del cliente, me acuerdo. Me acuerdo de que yo, con toda mi convicción sobre lo obvio que es que una foto vertical no cabe en un espacio horizontal, soy incapaz de distinguir mi derecha de mi izquierda de forma espontánea. Tengo que pensar. Tengo que buscar algún truco mental, alguna referencia física. Hay gente que nace sabiendo cuál es cuál y hay gente como yo, que a los cincuenta años todavía duda un segundo antes de señalar.

Claro, al resto de la gente le parece increíble que yo tenga ese problema. Le parece que debería ser evidente. Y yo les explico que lo sé, que claro que lo sé, pero que en el momento de la acción mi cerebro no lo procesa de forma automática. Y ellos asienten despacio, con esa expresión de educación y perplejidad que yo conozco tan bien desde el otro lado.

Así que al final parece que todos tenemos nuestra sandía y nuestro tarro de mermelada. Los míos solo están orientados en otra dirección.

La película que nadie recuerda bien

Flash Gordon se estrenó en 1980. La dirigió Mike Hodges —que venía de hacer Get Carter, una película de culto del cine negro británico, lo cual en retrospectiva es una combinación bastante extraña— y la produjo Dino De Laurentiis, que era el tipo de productor al que le gustaba apostar fuerte y a veces le salía bien y a veces no.

El caso es que la película existe, tiene cuarenta y tantos años, y casi nadie la ha visto. No está en las listas de clásicos de los ochenta. No sale en los artículos de "las mejores películas de ciencia ficción". Aparece de vez en cuando en algún hilo de nostalgia ochentera y poco más. Para una película con ese presupuesto, esa banda sonora y ese reparto, eso es bastante triste.

Lo que te encuentras cuando por fin la pones

La primera vez que la ves lo primero que piensas es que alguien se gastó una cantidad absurda de dinero en telas, pinturas y purpurina. Mongo, el planeta donde transcurre todo, es un universo de colores imposibles. Rojos, dorados, azules que no existen en la naturaleza. Los decorados parecen pintados a mano porque en muchos casos lo están, y tiene esa textura de teatro que hoy resulta rara pero también encantadora.

Y luego está el vestuario. Danilo Donati —que había trabajado con Fellini, con Zeffirelli— hizo los trajes, y se nota que se lo pasó en grande. Cada personaje lleva algo absolutamente ridículo y absolutamente perfecto al mismo tiempo. Los hombres halcón con sus alas, Ming con su túnica dorada y las cejas depiladas, Flash con su camiseta de los New York Jets que en algún momento decide que ya no necesita... es todo demasiado, en el mejor sentido.

Max von Sydow haciendo de Max von Sydow

Hay que hablar de Ming el Despiadado. O más concretamente, de Max von Sydow haciendo de Ming el Despiadado.

Von Sydow era en 1980 un actor de primerísimo nivel. Había trabajado con Bergman. Había jugado al ajedrez con la Muerte en El séptimo sello. Y aquí está, con la cabeza depilada, las cejas pintadas y una expresión de desprecio absoluto hacia toda la humanidad, completamente entregado al papel sin el menor asomo de ironía. No está haciendo el payaso. Está siendo Ming.

Siempre me ha parecido que un villano de cómic funciona o no dependiendo de si el actor que lo interpreta se lo cree de verdad. Von Sydow se lo cree absolutamente. Es lo mejor de la película, sin discusión.

Sam J. Jones, o el héroe que no termina de arrancar

Aquí hay que ser honesto. Flash Gordon es un quarterback de fútbol americano que acaba en el espacio prácticamente por accidente, y Sam J. Jones lo interpreta con una presencia física indudable y una profundidad emocional que... bueno. No es lo suyo.

Lo que hace más comprensible la cosa es que el rodaje fue un desastre en ese frente. Jones tuvo un conflicto con De Laurentiis, se fue antes de terminar, y parte de su doblaje lo hizo otra persona. Eso explica esa sensación extraña que tienes en algunas escenas de que el protagonista parece estar en una película diferente a la del resto del reparto.

No es el único protagonista del cine de los ochenta con ese problema, pero en Flash Gordon se nota más porque alrededor suyo todo el mundo está dándolo todo y él parece de visita.

El problema de la banda sonora, que es demasiado buena

Queen hizo la banda sonora. Esto todo el mundo lo sabe. Lo que quizás no se ha pensado mucho es que eso, siendo una cosa maravillosa, también es parte del problema.

Flash's Theme es un himno. The Hero es grandiosa. El disco entero es buenísimo y ha sobrevivido décadas perfectamente. El problema es que funciona sin la película. La música de Queen para Flash Gordon es tan buena por sí sola que se ha convertido en un objeto independiente que ya no necesita las imágenes que acompañaba.

Cuando alguien dice "Flash Gordon" y la primera reacción es tararear la canción, algo ha salido torcido en la relación entre la película y su banda sonora. No es culpa de Queen, obviamente. Pero el resultado es que la película ha quedado reducida a ser el contexto de la canción, en lugar de al revés. Y eso no le ha hecho ningún favor.

El momento equivocado

Flash Gordon llegó a los cines tres años y medio después de Star Wars. Eso importa más de lo que parece, porque Star Wars había cambiado completamente lo que el público esperaba de la ciencia ficción: efectos especiales que se creyeran, mundos que parecieran reales aunque fueran inventados.

Flash Gordon iba en dirección contraria: teatro, artificio, colores imposibles, una convención explícita de que todo es un espectáculo. En otro momento histórico eso habría sido una propuesta interesante. En 1980, después de Lucas, desorientó a todo el mundo.

El público que quería épica espacial encontró Mongo demasiado de juguete. El que disfrutaba del camp encontró la película demasiado seria para reírse con ella. Y así quedó en tierra de nadie.

Por qué vale la pena verla igual

Con todos esos problemas encima de la mesa, sigo pensando que Flash Gordon merece más atención de la que recibe. Tiene esa generosidad visual que hoy casi no existe: cada plano está lleno, cada decorado tiene detalle, cada traje tiene trabajo detrás. Es una película que se nota que la hizo gente que se lo estaba pasando bien, aunque luego todo se complicara.

Y tiene a Max von Sydow siendo Ming. Que ya es motivo suficiente.

Si nunca la has visto, ponla un viernes por la noche sin demasiadas expectativas. Si la viste hace veinte años y solo recuerdas la canción de Queen, dale otra oportunidad. Es imperfecta, es rara, a veces no sabes muy bien qué estás viendo. Pero es genuina. Y eso en el cine de hoy no abunda tanto como debería.

Como tutorial, además, es ideal. Mete sobre la mesa cosas que los seis juegos anteriores de esta serie no han tocado: la representación de las piezas como matrices que se rotan, la gestión del tiempo para una caída acompasada que se acelera con los niveles, y sobre todo la lógica de detección y eliminación de líneas, que es deceptivamente simple. Si has seguido los anteriores, este se va a sentir como un salto natural; si llegas nuevo, también funciona porque es un sistema autocontenido.

La idea general antes de tocar código

Hay un tablero rectangular de 10 columnas por 20 filas. Por arriba van apareciendo, una a una, piezas de cuatro celdas —los siete tetrominos clásicos— que caen automáticamente hacia abajo. El jugador puede moverlas a izquierda y derecha, rotarlas en su sitio, acelerar la caída o soltarlas de golpe. Cuando una pieza no puede bajar más porque hay suelo o porque se apoya en bloques ya fijados, se queda donde está y se convierte en parte del tablero. Aparece una nueva pieza arriba.

Cuando una fila se completa entera —diez bloques de la columna 0 a la 9—, esa fila se elimina y todo lo que había encima cae una posición. Cuanto más alto se acumulan los bloques, menos sitio queda para meter las nuevas piezas; el juego termina cuando una pieza nueva ya no cabe al aparecer. Eso es todo. La gracia está en que el ritmo de caída se va acelerando a medida que limpias líneas, así que el juego se va volviendo más exigente sin necesidad de cambiar las reglas.

La cuadrícula como matriz 2D

La estructura central de todo el juego es un array de arrays que representa el tablero. Diez columnas, veinte filas. Cada celda guarda o bien null (vacía) o bien el color del bloque que la ocupa. Lo organizamos como tablero[fila][columna], no al revés, porque así dibujar el tablero es un doble bucle natural por filas.

const COLUMNAS = 10;
const FILAS = 20;
const TAMANO = 30; // píxeles por celda

const ANCHO = COLUMNAS * TAMANO; // 300
const ALTO = FILAS * TAMANO; // 600

let tablero = Array.from({ length: FILAS }, () => Array(COLUMNAS).fill(null));

Ese Array.from({length: N}, () => Array(M).fill(null)) es la forma idiomática en JS para crear una matriz 2D sin compartir referencias entre filas. Si lo hicieras con Array(FILAS).fill(Array(COLUMNAS).fill(null)) —que parece lo mismo—, todas las filas serían el mismo array y modificar una modificaría todas. Es uno de los gotchas clásicos.

Las siete piezas como matrices

Cada pieza la representamos también como una pequeña matriz: 1 = bloque, 0 = hueco. La I es de 1×4, la O de 2×2, las demás de 2×3. Los colores los fijo siguiendo la paleta canónica de Tetris (cyan para la I, amarillo para la O, etcétera).

const PIEZAS = {
	I: [[1, 1, 1, 1]],
	O: [
		[1, 1],
		[1, 1],
	],
	T: [
		[0, 1, 0],
		[1, 1, 1],
	],
	L: [
		[0, 0, 1],
		[1, 1, 1],
	],
	J: [
		[1, 0, 0],
		[1, 1, 1],
	],
	S: [
		[0, 1, 1],
		[1, 1, 0],
	],
	Z: [
		[1, 1, 0],
		[0, 1, 1],
	],
};
const COLORES = {
	I: "#00d4d4",
	O: "#d4d400",
	T: "#a040c0",
	L: "#d48028",
	J: "#3050d0",
	S: "#40c440",
	Z: "#d44040",
};

Cuando aparece una pieza nueva, elegimos un tipo al azar y guardamos una copia de su matriz —no el original—, porque la pieza activa va a mutar (rotar) y no queremos contaminar la plantilla de su tipo:

function clonarMatriz(m) {
	return m.map((fila) => [...fila]);
}

function nuevaPieza() {
	const TIPOS = Object.keys(PIEZAS);
	const tipo = TIPOS[Math.floor(Math.random() * TIPOS.length)];
	pieza = { tipo, forma: clonarMatriz(PIEZAS[tipo]), color: COLORES[tipo] };
	x = Math.floor((COLUMNAS - pieza.forma[0].length) / 2);
	y = 0;
}

La pieza activa la guardamos como un objeto con tipo, forma y color, más dos variables x e y que indican la posición de su esquina superior izquierda dentro del tablero. Ese par (x, y) es lo único que cambia cuando la pieza se mueve.

La función colisiona: el corazón de todo

Antes de mover, rotar o fijar una pieza, hay que saber si el movimiento sería válido. Toda esa lógica vive en una sola función que centraliza la pregunta "¿cabe esta forma en esta posición?":

function colisiona(forma, px, py) {
	for (let f = 0; f < forma.length; f++) {
		for (let c = 0; c < forma[f].length; c++) {
			if (!forma[f][c]) continue; // celda vacía de la pieza, ignorar
			const tx = px + c;
			const ty = py + f;
			if (tx < 0 || tx >= COLUMNAS) return true; // fuera por los lados
			if (ty >= FILAS) return true; // fuera por abajo
			if (ty >= 0 && tablero[ty][tx]) return true; // pisa un bloque fijo
		}
	}
	return false;
}

Recibe la forma (no la pieza completa, solo su matriz) y una posición tentativa (px, py). Recorre cada celda de la forma; si la celda es 1, comprueba si su posición proyectada en el tablero saldría de los límites o pisaría un bloque ya fijado. Devuelve true en cuanto encuentra un problema.

Este detalle de no recibir pieza sino forma es importante: nos permite reutilizar la función para preguntar "¿cabría la pieza si la moviéramos un paso a la derecha?" o "¿cabría si la rotáramos?". Pasamos una posición o forma hipotética y obtenemos la respuesta sin tocar el estado real del juego.

Movimiento y caída

Con colisiona definida, mover lateralmente es trivial:

function moverHorizontal(dx) {
	if (!colisiona(pieza.forma, x + dx, y)) x += dx;
}

Si el movimiento no causaría colisión, lo aplicamos. Si causaría colisión, no hacemos nada y la pieza se queda donde estaba. Lo mismo para la caída paso a paso, con un matiz importante:

function moverAbajo() {
	if (!colisiona(pieza.forma, x, y + 1)) {
		y++;
		return true;
	}
	fijarPieza();
	return false;
}

Si la pieza puede bajar, baja. Si no, se fija al tablero. Es decir: el momento exacto en que una pieza colisionaría al bajar es el momento en que deja de ser pieza activa y pasa a ser parte permanente del tablero. Esa transición —de pieza-en-movimiento a bloques-fijos— es el latido del juego.

La rotación como transformación de matriz

La parte más bonita del tutorial. Rotar una pieza 90 grados en sentido horario es exactamente lo mismo que rotar su matriz: la columna 0 de la matriz original pasa a ser la última fila de la rotada (en orden inverso), la columna 1 pasa a ser la penúltima, y así. La fórmula es:

rotada[c][N - 1 - f] = original[f][c]

donde N es el número de filas de la matriz original. Implementado en código:

function rotar() {
	if (pieza.tipo === "O") return; // El cuadrado no cambia al rotar
	const N = pieza.forma.length;
	const M = pieza.forma[0].length;
	const nueva = Array.from({ length: M }, () => Array(N).fill(0));
	for (let f = 0; f < N; f++) {
		for (let c = 0; c < M; c++) {
			nueva[c][N - 1 - f] = pieza.forma[f][c];
		}
	}
	if (!colisiona(nueva, x, y)) pieza.forma = nueva;
}

Tres detalles de los que merece la pena hablar:

Primero, la pieza O es un cuadrado simétrico, así que rotarla no cambia nada visualmente. Saltamos esa rotación al inicio para no gastar trabajo. No es estrictamente necesario —la rotación del 2×2 da el mismo 2×2 y sería equivalente— pero es buena práctica.

Segundo, la matriz nueva tiene dimensiones invertidas: si la original era N×M, la rotada es M×N. Por eso la I, que era 1×4 (una fila de cuatro celdas), después de rotar es 4×1 (una columna de cuatro celdas). Si dibujáramos antes y después no veríamos un cuadrado raro, sino la barra vertical clásica.

Tercero, antes de aceptar la rotación verificamos que la nueva forma cabría en la posición actual. Si rotar la pieza la haría chocar con una pared o con bloques ya fijados, simplemente no rotamos. En implementaciones más sofisticadas existe el concepto de wall kick —si la rotación choca contra la pared, se intenta desplazar uno o dos espacios para que entre—, pero para una versión de tutorial limpia, no rotar es la decisión correcta.

Fijar la pieza al tablero

Cuando moverAbajo() falla, llamamos a fijarPieza. Esta función "imprime" la pieza activa en el tablero y luego intenta una nueva pieza:

function fijarPieza() {
	for (let f = 0; f < pieza.forma.length; f++) {
		for (let c = 0; c < pieza.forma[f].length; c++) {
			if (pieza.forma[f][c]) {
				if (y + f < 0) continue; // fuera del tablero por arriba: ignorar
				tablero[y + f][x + c] = pieza.color;
			}
		}
	}
	eliminarLineas();
	nuevaPieza();
}

El if (y + f < 0) evita escribir fuera del tablero cuando una pieza alta queda parcialmente arriba del techo —improbable pero defensivo—. Tras fijar, comprobamos si se han completado líneas y generamos una nueva pieza. Si la nueva pieza no cabe al aparecer, el juego ha terminado.

La eliminación de líneas

El núcleo conceptual del juego. Recorremos el tablero de abajo arriba, y cuando encontramos una fila donde todas las celdas tienen color (es decir, no hay ningún null), la quitamos del array y añadimos una nueva fila vacía por arriba:

function eliminarLineas() {
	let eliminadas = 0;
	for (let f = FILAS - 1; f >= 0; f--) {
		if (tablero[f].every((c) => c)) {
			tablero.splice(f, 1);
			tablero.unshift(Array(COLUMNAS).fill(null));
			eliminadas++;
			f++; // el splice ha desplazado todo hacia abajo, hay que re-mirar esta f
		}
	}
	if (eliminadas > 0) {
		const puntosPorN = [0, 100, 300, 500, 800];
		puntos += puntosPorN[eliminadas] * nivel;
		lineas += eliminadas;
		nivel = Math.floor(lineas / 10) + 1;
		intervaloCaida = Math.max(80, 800 - (nivel - 1) * 60);
	}
}

El detalle del f++ después de un splice merece comentario. Cuando eliminamos la fila f, todas las filas que estaban encima bajan una posición; la fila que ahora ocupa el índice f no la hemos comprobado. Si la dejamos pasar, podríamos saltarnos una línea completa que acaba de bajar. Por eso incrementamos f para compensar el f-- del bucle, manteniendo el índice. Es uno de esos pequeños bailes de índices que cuestan veinte minutos la primera vez que los escribes y cinco segundos cada vez después.

La puntuación sigue la tabla canónica de Tetris: 100 puntos por una línea, 300 por dos, 500 por tres y 800 por cuatro (el famoso Tetris, una sola jugada de 4 líneas a la vez). Multiplicado por el nivel actual, así que ir más rápido vale más. El nivel sube cada 10 líneas y la velocidad de caída baja con él, hasta un mínimo de 80ms por paso.

El bucle del juego con tiempo real

Esta es la primera vez en la serie que necesitamos tiempo real, no por frames. Si hiciéramos que la pieza bajara una posición cada requestAnimationFrame, en pantallas a 60Hz iría a 60 caídas por segundo. Lo que queremos es que baje según un intervalo en milisegundos que vamos ajustando con el nivel. La solución es acumular el delta de tiempo entre frames y avanzar la caída solo cuando hayamos acumulado el suficiente:

let ultimoTiempo = 0;
let contadorCaida = 0;
let intervaloCaida = 800;

function bucle(tiempo) {
	if (!ultimoTiempo) ultimoTiempo = tiempo;
	const delta = tiempo - ultimoTiempo;
	ultimoTiempo = tiempo;

	contadorCaida += delta;
	if (contadorCaida >= intervaloCaida) {
		moverAbajo();
		contadorCaida = 0;
	}

	dibujar();
	requestAnimationFrame(bucle);
}

requestAnimationFrame pasa al callback un timestamp en milisegundos. Restamos el tiempo del frame anterior para obtener cuánto ha pasado realmente, y vamos sumando ese delta a un contador. Cuando el contador supera el intervalo de caída actual, hacemos bajar la pieza y reseteamos. El resto del frame, dibujamos. Este patrón —acumular delta para acciones discretas— funciona para cualquier mecánica tipo "X cosa cada Y milisegundos" y es muy reutilizable.

Dibujado

La función de dibujo recorre el tablero pintando los bloques fijos y luego pinta la pieza activa encima. La rejilla tenue de fondo es opcional pero ayuda mucho a la legibilidad de las piezas:

function dibujarCelda(cx, cy, color) {
	ctx.fillStyle = color;
	ctx.fillRect(cx * TAMANO, cy * TAMANO, TAMANO, TAMANO);
	ctx.fillStyle = "rgba(255,255,255,0.18)";
	ctx.fillRect(cx * TAMANO, cy * TAMANO, TAMANO, 3); // brillo arriba
	ctx.fillStyle = "rgba(0,0,0,0.25)";
	ctx.fillRect(cx * TAMANO, cy * TAMANO + TAMANO - 3, TAMANO, 3); // sombra abajo
}

Las dos franjas adicionales —una clara arriba, una oscura abajo— dan a cada bloque un pequeño efecto de bisel que evita que el tablero se vea plano. Es el truco más barato para que un puzzle de cuadrículas no parezca una hoja de cálculo.

Controles

Asignamos las teclas estándar: izquierda/derecha mueven la pieza, arriba la rota, abajo acelera la caída por una celda (soft drop), espacio la suelta de golpe hasta el fondo (hard drop). Cada acción reinicia el contador de caída para evitar comportamientos raros como que pulsar abajo justo antes de un tick automático cuente como dos pasos:

document.addEventListener("keydown", (e) => {
	if (e.key === "ArrowLeft") moverHorizontal(-1);
	if (e.key === "ArrowRight") moverHorizontal(1);
	if (e.key === "ArrowUp") rotar();
	if (e.key === "ArrowDown") {
		moverAbajo();
		contadorCaida = 0;
	}
	if (e.key === " ") caidaInstantanea();
});

caidaInstantanea es un loop simple: mientras la pieza pueda bajar, baja; cuando ya no, fijamos:

function caidaInstantanea() {
	while (!colisiona(pieza.forma, x, y + 1)) y++;
	fijarPieza();
}

Cierre

Tetris funcionó en 1984 sobre una máquina sin gráficos y sigue funcionando hoy en una página HTML con menos de trescientas líneas de JavaScript. Los conceptos centrales —matriz 2D para el tablero, formas como matrices pequeñas, una función de colisión unificada, rotación por transposición de matriz, eliminación de líneas con splice + unshift, gravedad acompasada por delta time— son patrones que se repiten en muchos otros juegos del mismo género: Columns, Dr. Mario, Puyo Puyo, Lumines. Si has llegado hasta aquí entendiendo cada paso, en realidad has aprendido una familia entera de juegos, no uno solo.

La versión que tienes encima del artículo está embebida en la propia página y funciona con teclado en escritorio y con tap/swipe en móvil. Si quieres trastear con el código, lo tienes todo en una sola IIFE autocontenida; cambiar los colores, las dimensiones del tablero o la curva de velocidad es un par de constantes. Si quieres más profundidad, el siguiente nivel sería implementar el sistema de wall kicks (Super Rotation System), añadir un ghost piece que muestre dónde caería la pieza si la soltaras, y meter una pieza guardada (hold) que se pueda intercambiar con la actual. Son tres mejoras independientes que multiplican el placer del juego sin tocar la mecánica nuclear que acabamos de construir.

El embrollo del IRPF que nadie sabe gestionar

Cuando trabajas como autónomo persona física y tus clientes son principalmente pequeñas empresas y otros autónomos, cada factura que emites lleva una retención de IRPF. En teoría, el mecanismo es sencillo: tú facturas, tu cliente descuenta esa retención del total que te paga y se encarga de ingresarla a Hacienda en tu nombre. Tú, al hacer la declaración anual, ya tienes ese dinero adelantado al fisco y el resultado es más o menos equilibrado.

En teoría.

La realidad del tejido empresarial español es bastante más caótica. Una parte significativa de las pymes y los autónomos con los que trabajas no sabe gestionar correctamente esas retenciones. Algunos no saben que tienen esa obligación. Otros lo hacen mal. El resultado es que a final de año te encuentras ante una situación kafkiana: Hacienda considera que has ingresado unos rendimientos que en realidad no has cobrado íntegramente (porque parte era retención), pero esas retenciones tampoco han llegado al fisco. El dinero ha desaparecido en un limbo contable y tú tienes que ponerte a gestionar el caos cliente por cliente, factura por factura, reclamando unos importes que son técnicamente tuyos pero que nunca viste.

La solución que te propone cualquier asesor con experiencia es montar una sociedad limitada. Las SL no aplican retención de IRPF en sus facturas comerciales; eso se gestiona cuando la sociedad te paga a ti tu nómina. El problema desaparece del trato con clientes y se centraliza donde debería estar: en tu relación fiscal con tu propia empresa. Limpio, ordenado, lógico.

Y entonces descubres que eres autónomo societario.

Una categoría que nadie te anuncia

Constituyes la SL, te das de alta como administrador, y la Seguridad Social te encuadra silenciosamente en una figura que tiene nombre propio pero que muy poca gente conoce hasta que le afecta: el trabajador autónomo societario. Quien tiene más de un 25% de participación en una sociedad mercantil y ejerce funciones de dirección o gerencia entra automáticamente en esta categoría. No hay aviso previo, no hay folleto informativo, no hay nadie al otro lado de la ventanilla que te explique que acabas de cambiar de régimen y que eso tiene consecuencias.

A partir de ese momento, sigues siendo autónomo a todos los efectos —cotizas en el RETA, te abonas tu cuota mensual, rellenas los mismos modelos trimestrales— pero con un conjunto de restricciones y penalizaciones específicas que no comparten el resto de autónomos. Has resuelto el problema del IRPF y a cambio has entrado en una categoría especialmente maltratada por el sistema.

La base mínima de cotización: pagando por lo que no ganas

Uno de los cambios más recientes en el sistema de autónomos fue el paso a la cotización por ingresos reales, que se implantó de forma escalonada desde 2023. La idea es justa en su concepción: que cada trabajador por cuenta propia cotice en función de lo que realmente gana. Para los autónomos ordinarios, esto significa poder elegir bases de cotización bajas en los tramos inferiores de renta. Para el autónomo societario, no: la ley establece una base mínima obligatoria que no puede bajar de los 1.000 euros mensuales si ha estado dado de alta más de 90 días en el año.

La premisa implícita del legislador es que quien monta una sociedad lo hace porque gana mucho dinero. Es un prejuicio de clase disfrazado de normativa. La realidad —que cualquier asesor fiscal puede confirmar con su propia cartera de clientes— es que una enorme proporción de autónomos societarios son pequeños profesionales, consultores, diseñadores, programadores o técnicos que facturan cifras modestas y que optaron por la SL precisamente por los problemas que hemos descrito, no porque sean empresarios de éxito con cuentas en el extranjero.

Y si 2025 ya era injusto, 2026 ha sido directamente un golpe. La base mínima de cotización para autónomos societarios saltó de los 1.000 euros a los 1.424,40 euros mensuales, lo que significa que la cuota mínima mensual ha pasado de 314 euros a 448 euros. Un incremento de más del 42% de un año para otro. Un autónomo que factura 1.200 euros al mes y tiene gastos fijos está pagando su cuota de autónomo con dinero que no gana. El sistema considera que eso es imposible. El sistema se equivoca.

La tarifa plana: un derecho recuperado a regañadientes

Hasta bien entrado 2020, los autónomos societarios directamente no tenían acceso a la tarifa plana de arranque —esa reducción de la cuota mensual durante el primer año de actividad que se creó como incentivo al emprendimiento. La Seguridad Social interpretaba que la figura del societario era incompatible con el espíritu de la medida. Hubo que llegar a varias sentencias del Tribunal Supremo para que el criterio cambiara y los nuevos autónomos societarios pudieran acogerse a los 80 euros mensuales del primer año.

El problema es que esas sentencias tienen efecto retroactivo de solo cuatro años, lo que significa que todos los autónomos societarios que pagaron de más antes de ese cambio de criterio y que habían superado ese plazo perdieron su derecho a reclamación. El Estado se benefició durante años de una interpretación restrictiva que los tribunales acabaron declarando injusta, y luego limitó la reparación para que afectara al menor número posible de personas. No fue un error administrativo que se corrigió con diligencia; fue una posición sostenida hasta que se hizo insostenible.

La jubilación activa: el cierre que nadie esperaba

La jubilación activa es el sistema que permite compatibilizar el cobro de la pensión con la continuidad de la actividad laboral. Para muchos autónomos mayores que no quieren o no pueden retirarse de golpe, es una herramienta fundamental de transición. Para los autónomos societarios con control efectivo de su empresa —es decir, para la mayoría— el acceso es extremadamente complicado.

La Seguridad Social ha mantenido históricamente un criterio restrictivo: como la jubilación del societario no implica la extinción de los contratos de sus trabajadores (la SL sobrevive), no se cumple la finalidad de "conservación del empleo" que justifica la medida. Y tras los cambios normativos de abril de 2025, la situación ha empeorado: ya no es posible cobrar el 100% de la pensión desde el primer día para quien solo realiza funciones de propiedad sin trabajo efectivo. El acceso pleno exige acumular años de demora de la jubilación o reorganizar el rol dentro de la empresa de una forma que en muchos casos resulta artificial o directamente impracticable.

Una vez más, la persona física que ha trabajado toda su vida y llega a los 67 años tiene más margen de maniobra que el societario que ha construido exactamente la misma trayectoria pero a través de una estructura mercantil.

El paro que existe pero no existe

Desde 2019, los autónomos cotizan obligatoriamente por cese de actividad, lo que se presentó en su momento como el gran avance que equiparaba a los trabajadores por cuenta propia con los asalariados en materia de protección ante el desempleo. En la práctica, la equiparación es más nominal que real.

El cese de actividad tiene requisitos de acceso estrictos —hay que acreditar causas económicas, técnicas, productivas u organizativas de suficiente entidad— y su duración máxima es considerablemente inferior a la de una prestación contributiva por desempleo equivalente. No es el paro; es una prestación temporal con condiciones de acceso más exigentes. Para el autónomo societario, además, la relación entre sus ingresos reales como administrador y los rendimientos de la sociedad añade capas de complejidad que pueden dificultar aún más la acreditación de las causas que dan derecho al cese.

Y cuando se agota esa prestación, o cuando nunca se cumplieron los requisitos para acceder a ella, ¿qué queda?

El subsidio de los 52 que nunca llegará

El subsidio para mayores de 52 años del SEPE es una de las protecciones más importantes del sistema para trabajadores que se quedan sin empleo cerca de la edad de jubilación. Permite seguir cotizando hasta los 65 o 67 años y proporciona unos ingresos de alrededor de 480 euros mensuales mientras se busca trabajo o se espera la pensión. Para los autónomos, incluyendo los societarios, ese subsidio no existe.

El motivo técnico es que para acceder a él hay que haber cotizado al menos seis años por desempleo en el Régimen General, algo que los autónomos no hacen porque cotizan en el RETA y por cese de actividad. El SEPE lo deniega sistemáticamente aunque el autónomo lleve treinta años cotizando sin interrupción y haya construido toda su vida profesional trabajando para sí mismo. Las organizaciones de autónomos llevan años reclamando el acceso a esta protección; el Ministerio de Trabajo responde que "el ámbito de la reforma del desempleo asistencial es el trabajo por cuenta ajena". Punto final.

Lo mismo ocurre con las ayudas de complemento salarial hasta el Ingreso Mínimo Vital para personas en activo: el diseño de esas prestaciones asistenciales parte de la figura del trabajador asalariado y no contempla adecuadamente la realidad del autónomo que factura poco y tiene meses con ingresos muy irregulares.

¿Qué queda, entonces?

Lo que queda es seguir trabajando. Sin red de seguridad real si la actividad flaquea. Sin jubilación activa si quieres retirarte progresivamente. Sin subsidio si llegas a los 52 con el negocio cerrado. Sin tarifa plana histórica si la montaste antes de que el Supremo dijera lo que era de sentido común. Sin poder cotizar por lo que realmente ganas si tus ingresos son bajos.

La figura del autónomo societario nació como una solución práctica a problemas concretos del mercado laboral español —la complejidad fiscal, la gestión de retenciones, la separación del patrimonio personal y profesional— y el sistema la ha convertido en un cajón donde acumular restricciones y excepciones desfavorables con la excusa de que quien monta una sociedad debe de ser rico.

El resultado es una categoría de trabajadores que cotiza más que el resto, tiene acceso a menos prestaciones, y cuya única salida cuando el cuerpo o el mercado dicen basta es seguir adelante. No por vocación, sino porque el sistema no ha dejado otra puerta abierta.

Quizás algún día alguien en la Seguridad Social visite la realidad de las pequeñas sociedades unipersonales españolas antes de diseñar la siguiente norma. Mientras tanto, toca seguir facturando.

Conviene aclarar un matiz desde el principio: el autónomo persona física tributa con su DNI como NIF fiscal, así que en ese caso el documento de la persona y el del contribuyente son el mismo. Pero en cuanto hay una sociedad de por medio —una limitada, una cooperativa, una fundación—, aparece el CIF, y con él un algoritmo de validación completamente distinto que merece su propio tratamiento.

El NIF —Número de Identificación Fiscal— es el identificador fiscal único en España. Para las personas físicas españolas equivale al DNI; para los extranjeros residentes es el NIE; para las personas jurídicas (empresas, asociaciones, organismos públicos...) es lo que durante décadas se llamó CIF y que desde 2008 se denomina oficialmente NIF de persona jurídica, aunque en la práctica todo el mundo sigue llamándolo CIF. Los tres conviven en el mismo campo.

DNI y NIE: terreno conocido

El DNI y el NIE son los mismos que ya conocemos. Ocho dígitos más una letra de control para el DNI; la letra inicial X, Y o Z seguida de siete dígitos y una letra de control para el NIE. En ambos casos la letra se calcula con el mismo algoritmo: módulo 23 del número sobre la cadena TRWAGMYFPDXBNJZSQVHLCKE.

No voy a repetir aquí los detalles porque los tienes explicados con calma en el artículo sobre documentos de identidad. Lo que sí importa para el validador de NIF es tener claro que estos dos formatos hay que detectarlos primero, antes de intentar interpretar lo que queda como un CIF.

El CIF: una letra de tipo y un carácter de control que puede ser letra o dígito

El CIF tiene una estructura diferente: una letra que identifica el tipo de entidad, seguida de siete dígitos, y un carácter final de control que —y aquí viene el primer matiz— puede ser tanto una letra como un dígito, dependiendo del tipo de entidad.

La letra inicial indica la naturaleza jurídica: A para sociedades anónimas, B para limitadas, F para cooperativas, G para asociaciones y fundaciones, Q para organismos públicos, y así hasta una veintena de opciones. Esa letra no es solo cosmética: condiciona qué tipo de carácter de control es válido al final.

[Letra de tipo] + [7 dígitos] + [Letra o dígito de control]

Ejemplo: A  1 2 3 4 5 6 7  4
         ^  ───────────── ^
    tipo S.A.   dígitos   control

La regla para el carácter de control es esta: los tipos P, Q, S y W (corporaciones locales, organismos públicos, órganos de la Administración y establecimientos permanentes de entidades no residentes) deben terminar siempre con una letra. El resto de tipos aceptan indistintamente letra o dígito —ambos son representaciones válidas del mismo valor.

El algoritmo del CIF, paso a paso

El cálculo del carácter de control opera sobre los siete dígitos centrales y sigue este proceso:

Se recorre cada dígito teniendo en cuenta su posición. Los que ocupan posiciones impares (primera, tercera, quinta y séptima) se multiplican por dos; si el resultado supera nueve, se suman sus dos cifras —igual que en otros algoritmos de Luhn. Los que ocupan posiciones pares se usan directamente sin transformación. Se suman todos los valores resultantes.

Con esa suma, el índice de control es (10 − (suma % 10)) % 10. Ese índice sirve para dos cosas: como dígito de control directamente, y como posición en la cadena JABCDEFGHI para obtener la letra de control equivalente.

const LETRAS_CIF = "JABCDEFGHI";

function calcularControlCIF(tipo, digitos) {
	let suma = 0;
	for (let i = 0; i < 7; i++) {
		let d = parseInt(digitos[i], 10);
		if ((i + 1) % 2 !== 0) {
			// posición impar (base 1)
			d *= 2;
			if (d >= 10) d = Math.floor(d / 10) + (d % 10);
		}
		suma += d;
	}
	const idx = (10 - (suma % 10)) % 10;
	return { digit: String(idx), letter: LETRAS_CIF[idx] };
}

Con el índice en mano, la validación es directa: el carácter final del CIF debe coincidir con el dígito calculado o con la letra calculada. Si el tipo de entidad pertenece al grupo PQSW y el carácter es un dígito, el CIF no es válido aunque el valor sea matemáticamente correcto.

function validateCIF(value) {
	const cif = normalizar(value);
	const match = cif.match(/^([ABCDEFGHJNPQRSTUVW])(\d{7})([0-9A-J])$/);
	if (!match) return { valid: false, type: "CIF", error: "formato_incorrecto" };

	const [, tipo, digitos, control] = match;
	const { digit, letter } = calcularControlCIF(tipo, digitos);

	if ("PQSW".includes(tipo) && /\d/.test(control)) {
		return { valid: false, type: "CIF", error: "control_debe_ser_letra" };
	}

	const ok = control === digit || control === letter;
	return {
		valid: ok,
		type: "CIF",
		value: cif,
		entityType: tipo,
		entityName: TIPOS_CIF[tipo] || null,
		error: ok ? undefined : "caracter_control_incorrecto",
	};
}

Detectar automáticamente qué tipo de NIF es

Con los tres validadores listos, la función principal se limita a mirar el formato y derivar al validador correcto. El orden importa: hay que comprobar primero DNI y NIE —cuya primera posición puede solaparse con letras válidas de CIF— antes de intentar interpretar la cadena como un CIF.

function validate(raw) {
	const doc = normalizar(raw);
	if (!doc) return { valid: false, type: null, error: "vacio" };

	if (/^\d{8}[A-Z]$/.test(doc)) return validateDNI(doc);
	if (/^[XYZ]\d{7}[A-Z]$/.test(doc)) return validateNIE(doc);
	if (/^[ABCDEFGHJNPQRSTUVW]\d{7}[0-9A-J]$/.test(doc)) return validateCIF(doc);

	return { valid: false, type: null, value: doc, error: "tipo_no_reconocido" };
}

Vale la pena detenerse en el regex del CIF. La clase de caracteres [ABCDEFGHJNPQRSTUVW] para la letra inicial excluye explícitamente I y O por riesgo de confusión visual, y también X, Y y Z, que ya están capturadas por el patrón NIE. Para el carácter final, [0-9A-J] cubre tanto los diez posibles dígitos como las diez letras posibles de la tabla JABCDEFGHI.

Un resultado rico: más que un booleano

La ventaja de devolver un objeto estructurado en lugar de un simple true/false es que el formulario puede reaccionar de manera diferente según el tipo de NIF validado. Si es un CIF, puedes mostrar el tipo de entidad; si es un DNI o NIE inválido, puedes ofrecer un mensaje específico sobre la letra de control; si el formato no es reconocido, puedes sugerir un ejemplo.

const resultado = IdeFormsNIF.validate(campo.value);

if (resultado.valid && resultado.type === "CIF") {
	mostrarInfo(`Empresa registrada como: ${resultado.entityName}`);
}

if (!resultado.valid && resultado.error === "caracter_control_incorrecto") {
	mostrarError("La letra o dígito de control no es correcto para este NIF");
}

Ese nivel de detalle es lo que marca la diferencia entre un formulario que rechaza sin explicar y uno que ayuda al usuario a corregir el problema.

Qué cubre esta validación y qué no

El validador confirma que el NIF tiene un formato correcto y que el carácter de control es matemáticamente válido. No verifica que el NIF esté dado de alta en la Agencia Tributaria, que la empresa exista o que el DNI pertenezca a quien lo introduce. Para eso habría que consumir servicios externos —y entrar en territorios de privacidad y normativa que están bastante más allá de un campo de formulario.

Con este validador y los dos anteriores de la serie —documentos de identidad e IBAN—, tienes cubiertos los tres identificadores que aparecen con más frecuencia en formularios de facturación y contratación en España.

A continuación puedes encontrar un validador funcional que cubre los tres casos: detecta automáticamente si el documento es un DNI, un NIE o un CIF, valida el carácter de control y, en el caso del CIF, identifica el tipo de entidad.

LQIP — Low Quality Image Placeholder — es la técnica que llena ese hueco: durante la espera muestro una versión diminuta y borrosa de la imagen, y cuando la real termina de descargar, sustituyo una por la otra con un cross-fade. Es lo que hace Medium desde hace años, y antes lo hizo Pinterest.

La técnica en sí está documentada en mil sitios. Lo que cuento aquí es cómo la implementé en Idenautas, que corre sobre Lume: el script Deno que genera los placeholders en build, cómo los incrusto en el HTML, y cómo encajo todo en _config.ts sin meter JavaScript de cliente más allá del onload del propio <img>.

La idea

Tres decisiones que conviene fijar antes de escribir nada:

1. El placeholder se genera en build, no en runtime. El servidor (o el CDN, en mi caso Bunny) no tiene que hacer nada en cada visita. La consecuencia es que el placeholder viaja inline en el HTML como data:image/jpeg;base64,... y aparece sin una sola petición HTTP adicional.
2. El placeholder es una versión de 16 píxeles de ancho de la propia imagen, en JPG. A esa resolución el peso ronda los 300-500 bytes. Codificado en base64 son unos ~600 bytes por imagen — irrelevante en el HTML.
3. El cross-fade lo hace el navegador. El <img> lleva un onload que añade la clase .loaded a su contenedor, y el CSS hace el resto con opacity y transition. Cero JavaScript propio, cero IntersectionObserver, cero librerías.

El truco está en que las tres decisiones son interdependientes. Si genero el placeholder en runtime, no puedo incrustarlo. Si no es minúsculo, no puedo permitirme incrustarlo en cada <img>. Si no lo incrusto, necesito una segunda petición HTTP solo para el placeholder, y eso elimina la mitad de la ventaja.

El script: scripts/lqip.ts

El script tiene tres responsabilidades: encontrar las imágenes que se usan en el sitio, descargar su versión de 16 píxeles del CDN, y guardar el resultado en un JSON cacheable.

Descubrir las imágenes referenciadas

No quiero mantener una lista de imágenes a mano. El script camina src/ con @std/fs/walk y busca dos patrones en los archivos .md, .vto, .njk y .ts:

• Llamadas a los shortcodes {{ img("ruta") }} y {{ cardPicture("ruta") }}.
• La clave heroImage: en el frontmatter.

const SHORTCODE_RE =
	/(?:\{%[-\s]*|\{\{[-\s]*(?:await\s+)?)(?:img|cardPicture)\s*\(?\s*["']([^"']+)["']/g;
const HERO_RE = /^heroImage:\s*(.+)$/m;

async function findImagePaths(): Promise<string[]> {
	const paths = new Set<string>();
	for await (const entry of walk(SRC_DIR, {
		exts: [".md", ".vto", ".njk", ".ts"],
		skip: [/node_modules/, /_data\/lqip\.json$/],
	})) {
		if (!entry.isFile) continue;
		const content = await Deno.readTextFile(entry.path);
		let m: RegExpExecArray | null;
		SHORTCODE_RE.lastIndex = 0;
		while ((m = SHORTCODE_RE.exec(content)) !== null) paths.add(m[1]);
		const hero = content.match(HERO_RE);
		if (hero) paths.add(hero[1].trim().replace(/^["']|["']$/g, ""));
	}
	return [...paths];
}

El regex de los shortcodes acepta tanto la sintaxis Nunjucks heredada ({% img "..." %}) como la nueva de Vento ({{ img("...") }}). Migrar de una a otra es trabajo que hago a fuego lento, así que el script tiene que entender ambas durante el periodo de transición.

Es una solución imperfecta —un parser real entendería el código sin riesgo de falsos positivos—, pero a la práctica el regex acierta en el 100% de los casos del sitio. Si una imagen se referencia desde un layout o un sitio menos estándar, basta con añadir su patrón al regex.

Descargar los placeholders del CDN

Las imágenes de Idenautas viven en Bunny Storage y el build no las regenera: las versiones a 480 px, 800 px, 1200 px, 1920 px y 16 px (esta última, mi placeholder) ya están subidas con sufijo en el nombre. La ruta de cada placeholder es predecible:

function imgBase(imgPath: string): string {
	const i = imgPath.lastIndexOf(".");
	return i >= 0 ? imgPath.slice(0, i) : imgPath;
}

// imgBase("portada.jpg") + "-16.jpg" → "portada-16.jpg"

Para cada imagen, descargo ${CDN}${base}-16.jpg y la convierto a data URI:

async function fetchBase64(url: string): Promise<string> {
	const res = await fetch(url);
	if (!res.ok) throw new Error(`HTTP ${res.status}`);
	const type = res.headers.get("content-type") ?? "image/jpeg";
	const bytes = new Uint8Array(await res.arrayBuffer());
	return `data:${type};base64,${encodeBase64(bytes)}`;
}

encodeBase64 viene de jsr:@std/encoding/base64. Es una primitiva de la librería estándar de Deno; no añado dependencias.

El cache: src/_data/lqip.json

El detalle que marca la diferencia entre un script aceptable y uno usable a diario es el cache. Sin cache, cada npm run publicar haría tantas peticiones HTTP como imágenes hay en el sitio. Con cache, solo se descargan las nuevas:

let existing: Record<string, string> = {};
try {
	existing = JSON.parse(await Deno.readTextFile(OUTPUT));
} catch {
	// primera ejecución, no hay cache
}

const lqip: Record<string, string> = {};
let downloaded = 0;
for (const img of images) {
	if (existing[img]) {
		lqip[img] = existing[img];
		continue;
	}
	const url = `${CDN}${imgBase(img)}-16.jpg`;
	try {
		lqip[img] = await fetchBase64(url);
		downloaded++;
	} catch (err) {
		console.error(`  [lqip] ✗ ${img}: ${(err as Error).message}`);
	}
}

El JSON resultante es un mapa ruta-original → data URI. El script lo guarda en src/_data/lqip.json solo si el contenido ha cambiado — escribir el archivo en cada build invalidaría el watcher de Lume sin necesidad y dispararía recargas en desarrollo:

const prevJson = JSON.stringify(existing, null, 2);
const nextJson = JSON.stringify(lqip, null, 2);
if (prevJson !== nextJson) {
	await Deno.writeTextFile(OUTPUT, nextJson);
}

Otra ventaja del JSON cacheado: las imágenes que ya no se referencian desde ningún lado se eliminan del mapa automáticamente, porque el script reconstruye el objeto desde cero a partir del escaneo. No necesita una lógica de garbage collection aparte.

Integración con Lume

El script expone una función generateLQIP() para poder llamarse desde _config.ts. La conexión es mínima:

import { generateLQIP } from "./scripts/lqip.ts";

let lqipData: Record<string, string> = {};
try {
	lqipData = JSON.parse(await Deno.readTextFile("./src/_data/lqip.json"));
} catch {
	// primer build, todavía no hay cache
}

site.addEventListener("beforeBuild", async () => {
	lqipData = await generateLQIP({ quiet: false });
});

Dos detalles aquí:

• Carga del cache al arrancar. El JSON.parse inicial existe para que los servidores de desarrollo en frío arranquen con el mapa ya rellenado, sin esperar a la primera regeneración.
• beforeBuild y no beforeUpdate. En desarrollo, mientras edito un post, no quiero que cada cambio dispare una conexión al CDN. La regeneración solo ocurre en builds completos.

Con lqipData en memoria, los shortcodes que generan el HTML pueden consultarlo:

site.data("img", function (imgPath: string, alt: string, ...) {
  const lqip = lqipData[imgPath] || imgUrl(imgPath, 16, "jpg");
  return `<div class="lqip-wrap" style="background-image:url('${lqip}')">
    <picture>...</picture>
  </div>`;
});

El fallback || imgUrl(imgPath, 16, "jpg") cubre el caso en el que añado una imagen al post pero todavía no he regenerado el cache. En vez de quedarme sin placeholder, sirvo la URL del placeholder directamente desde el CDN — funciona, solo es marginalmente menos eficiente porque el navegador hace una petición HTTP extra mientras llega la imagen real.

El HTML resultante

Para cada imagen, el shortcode produce este HTML:

<div
	class="lqip-wrap"
	style="background-image:url('data:image/jpeg;base64,/9j/4AAQ...')">
	<picture>
		<source type="image/avif" srcset="foto-480.avif 480w, ..." sizes="..." />
		<source type="image/webp" srcset="foto-480.webp 480w, ..." sizes="..." />
		<img
			src="foto-1200.jpg"
			srcset="foto-480.jpg 480w, ..."
			sizes="..."
			alt="..."
			loading="lazy"
			width="1200"
			height="800"
			onload="this.parentNode.classList.add('loaded')" />
	</picture>
</div>

Tres piezas:

• El wrapper lleva el placeholder como background-image. Aparece instantáneo: ya viaja en el HTML.
• El <picture> sirve la imagen definitiva con srcset para densidades y formatos modernos. Eso es ortogonal al LQIP — es la técnica de imágenes responsive, aplicada a la imagen real.
• El onload añade .loaded al wrapper cuando el <img> termina de descargar, lo que dispara el cross-fade.

El CSS: cross-fade sin JavaScript

.lqip-wrap {
	position: relative;
	background-size: cover;
	background-position: center;
	background-repeat: no-repeat;
	overflow: hidden;
	width: 100%;
	height: 100%;
}

.lqip-wrap > img {
	display: block;
	width: 100%;
	height: 100%;
	object-fit: cover;
	opacity: 0;
	transition: opacity 0.4s ease;
}

.lqip-wrap.loaded > img {
	opacity: 1;
}

El placeholder es el fondo del wrapper. El <img> empieza con opacity: 0, ocupando el mismo espacio. Cuando dispara su onload, el wrapper recibe .loaded, el <img> pasa a opacity: 1, y la transición de 0,4 s hace el cross-fade.

object-fit: cover se asegura de que la imagen real cubra el wrapper sin deformarse, lo que importa porque el width y height del <img> definen la proporción pero el contenedor real lo controla CSS.

Por qué 16 píxeles y por qué JPG

Probé valores entre 8 y 32 píxeles. Por debajo de 16 el placeholder se nota pixelado en la transición; por encima, el peso crece más rápido que la mejora visual. El JPG a 16 px y calidad por defecto pesa unos 350 bytes — aceptable.

Sobre el formato: aquí JPG gana a WebP y AVIF. A 16 píxeles las cabeceras de WebP/AVIF representan un porcentaje ridículamente alto del archivo, y la ganancia de compresión sobre JPG es marginal. Además, los placeholders viajan en el HTML, donde el ahorro de bytes brutos sí cuenta — y JPG genera buffers pequeños y predecibles. He medido los tres formatos: a 16 px, JPG es el más ligero en mi caso.

Por qué no BlurHash, Plaiceholder o transform_images

Existen alternativas conocidas:

• BlurHash codifica el placeholder como un string ASCII de unos 30 caracteres y lo reconstruye con JavaScript en el cliente. El string es más compacto que una data URI base64, sí — pero requiere ~3 KB de JavaScript en cada página y un canvas para reconstruir el placeholder. Para una web sin frameworks no compensa.
• Plaiceholder es una librería de Node.js que genera LQIPs (entre otros formatos: blurhash, color dominante, SVG). En Idenautas no me hace falta el paso de generar la imagen pequeña — Bunny ya tiene la versión de 16 px subida —, y prefiero un script de cien líneas que entiendo entero a una dependencia más.
• El plugin oficial transform_images procesa imágenes con Sharp dentro del propio build de Lume. No genera placeholders como tales, pero sí puede producir la variante de 16 px y leerla luego para incrustarla en base64 — todo en una sola pasada de Lume, sin un script aparte como el mío. Si dejas que Lume gestione también tus variantes responsive con transform_images o el plugin picture, esa ruta es más coherente. En Idenautas las variantes están subidas a Bunny Storage por un pipeline anterior a Lume, así que el script de LQIP solo se ocupa del placeholder; si arrancase el proyecto desde cero hoy, probablemente movería todo el flujo de imágenes a transform_images y haría el LQIP ahí mismo.

Si fuera un proyecto donde las imágenes solo viven a tamaño completo y necesito regenerarlas, transform_images (o sharp directamente) sería la opción razonable. Mi pipeline ya produce las variantes responsive con un script aparte, así que añadir -16.jpg a esa lista era trivial.

Lo que cuesta y lo que aporta

El coste, en bytes incrustados, es de unos 600 bytes por imagen en el HTML. En una página con cinco imágenes son 3 KB extra antes de cualquier compresión gzip — y gzip los reduce todavía más, porque las cabeceras JPG son repetitivas entre placeholders. Es un coste muy bajo para evitar huecos vacíos en la primera pintada.

Lo que aporta es perceptual: la página se siente más rápida sin serlo necesariamente. Las imágenes ya están en su sitio cuando entras, solo enfocan. El usuario rara vez identifica conscientemente la técnica, pero nota la diferencia cuando la quitas.

Es una de esas inversiones de unas pocas horas que se quedan trabajando en silencio durante años. Y en Lume, con un script Deno y un evento beforeBuild, encaja sin necesidad de plugins ni configuración adicional.

Lo bonito de este juego como proyecto educativo es que junta en una sola pieza los conceptos de varios tutoriales anteriores. La física de la pelota es prácticamente la misma que en Pong. La detección de colisiones es la misma que con la paleta, pero ahora aplicada a docenas de objetos a la vez. Y aparece por primera vez en la serie un concepto nuevo: la gestión de muchos objetos del mismo tipo (los ladrillos) y la lógica de eliminarlos cuando son golpeados. Si has seguido los tutoriales anteriores, este se va a sentir como una continuación natural y bastante satisfactoria.

La idea general antes de tocar código

El juego funciona así. La pantalla está dividida en tres zonas: una paleta horizontal en la parte inferior que el jugador mueve a izquierda y derecha, una pelota que se mueve con velocidad continua y rebota contra los bordes, la paleta y los ladrillos, y una rejilla de ladrillos en la parte superior que hay que destruir. La pelota empieza pegada a la paleta y se lanza con un click o una tecla. Cuando rebota contra un ladrillo, el ladrillo se rompe y desaparece, y la pelota cambia de dirección. Si la pelota se sale por debajo de la paleta, el jugador pierde una vida. Si se rompen todos los ladrillos, ha terminado el nivel.

A diferencia de Pong, que es un duelo entre dos jugadores, este es un juego solitario contra el escenario. La estrategia no consiste en ganarle a nadie sino en controlar la trayectoria de la pelota para llegar a los ladrillos más difíciles antes de que la pelota se descontrole y termine cayéndose. Por eso, igual que en Pong, conviene que el ángulo de rebote dependa del punto donde la pelota toca la paleta. Eso es lo que separa una versión sin gracia de una realmente jugable.

El esqueleto HTML y CSS

Vamos con canvas, igual que con Snake o Pong, porque tenemos movimiento continuo y muchos objetos que pintar.

<!DOCTYPE html>
<html lang="es">
	<head>
		<meta charset="UTF-8" />
		<title>Ladrillos</title>
		<style>
			body {
				display: flex;
				flex-direction: column;
				align-items: center;
				background: #1a1d24;
				color: #e8e8e8;
				font-family: system-ui, sans-serif;
			}
			canvas {
				background: #0f1115;
				border: 1px solid #2a2e36;
			}
		</style>
	</head>
	<body>
		<h1>Ladrillos</h1>
		<div>
			Puntos: <span id="puntos">0</span> · Vidas: <span id="vidas">3</span>
		</div>
		<canvas id="lienzo" width="480" height="600"></canvas>
		<script>
			// aquí irá todo el código del juego
		</script>
	</body>
</html>

He elegido un canvas vertical de 480 por 600 píxeles porque para este tipo de juego es la proporción más natural. Necesitas espacio vertical para que la pelota tenga recorrido entre la pared de ladrillos y la paleta. Las proporciones horizontales típicas de un Snake o un Pong harían que la pelota cruce la pantalla demasiado deprisa.

El estado del juego

El estado tiene cuatro piezas: la pelota con su posición y velocidad, la paleta con su posición horizontal, un array de ladrillos con su posición y un flag de si están vivos, y los marcadores de puntos y vidas.

const ANCHO = 480;
const ALTO = 600;
const ANCHO_PALETA = 80;
const ALTO_PALETA = 12;
const TAMANO_PELOTA = 10;
const FILAS_LADRILLOS = 5;
const COLUMNAS_LADRILLOS = 8;
const ANCHO_LADRILLO = 54;
const ALTO_LADRILLO = 18;
const MARGEN_LADRILLOS = 6;

let pelota = { x: 0, y: 0, vx: 0, vy: 0 };
let paleta = { x: ANCHO / 2 - ANCHO_PALETA / 2 };
let ladrillos = [];
let puntos = 0;
let vidas = 3;
let pegada = true;

Aquí hay una variable que conviene explicar: pegada. Es un booleano que indica si la pelota está pegada a la paleta esperando a ser lanzada, o si ya está en movimiento. Al inicio de cada vida la pelota empieza pegada a la paleta y se mueve con ella. Cuando el jugador pulsa espacio o hace click, se despega y empieza el juego. Es una mecánica clásica del Breakout y Arkanoid originales que conviene respetar.

Generar los ladrillos

Los ladrillos son una rejilla regular en la parte superior de la pantalla. Para crearlos basta con dos bucles anidados que generen una entrada en el array por cada combinación de fila y columna.

function generarLadrillos() {
	ladrillos = [];
	const colores = ["#e74c3c", "#e67e22", "#f1c40f", "#27ae60", "#3498db"];
	const offsetX =
		(ANCHO -
			(COLUMNAS_LADRILLOS * (ANCHO_LADRILLO + MARGEN_LADRILLOS) -
				MARGEN_LADRILLOS)) /
		2;
	const offsetY = 60;

	for (let f = 0; f < FILAS_LADRILLOS; f++) {
		for (let c = 0; c < COLUMNAS_LADRILLOS; c++) {
			ladrillos.push({
				x: offsetX + c * (ANCHO_LADRILLO + MARGEN_LADRILLOS),
				y: offsetY + f * (ALTO_LADRILLO + MARGEN_LADRILLOS),
				color: colores[f],
				puntos: (FILAS_LADRILLOS - f) * 10,
				vivo: true,
			});
		}
	}
}

Cada ladrillo tiene su posición, su color, una puntuación que da al ser destruido y un flag vivo que dice si todavía está en pantalla. He hecho que las filas superiores valgan más puntos que las inferiores, que es la convención clásica del juego: los ladrillos más difíciles de alcanzar (los que están arriba, escondidos detrás de los demás) recompensan más al jugador. El cálculo de offsetX puede parecer farragoso pero solo está centrando la rejilla horizontalmente: calcula el ancho total que ocuparán todas las columnas con sus márgenes y reparte el espacio sobrante a izquierda y derecha por igual.

Mover la pelota y rebotes en bordes

El movimiento de la pelota es esencialmente igual que en Pong. La diferencia es que ahora rebota contra tres lados (izquierdo, derecho y superior) y por el cuarto (inferior) la pelota se sale y el jugador pierde una vida.

function actualizarPelota() {
	if (pegada) {
		pelota.x = paleta.x + ANCHO_PALETA / 2 - TAMANO_PELOTA / 2;
		pelota.y = ALTO - ALTO_PALETA - TAMANO_PELOTA - 5;
		return;
	}

	pelota.x += pelota.vx;
	pelota.y += pelota.vy;

	if (pelota.x < 0) {
		pelota.x = 0;
		pelota.vx = -pelota.vx;
	}
	if (pelota.x + TAMANO_PELOTA > ANCHO) {
		pelota.x = ANCHO - TAMANO_PELOTA;
		pelota.vx = -pelota.vx;
	}
	if (pelota.y < 0) {
		pelota.y = 0;
		pelota.vy = -pelota.vy;
	}
	if (pelota.y > ALTO) {
		perderVida();
	}
}

Si la pelota está pegada, no se mueve por su cuenta sino que se ancla a la posición de la paleta. Esto es lo que hace que la pelota acompañe a la paleta cuando el jugador la mueve antes de lanzar. En el momento en que el jugador lanza, pegada se vuelve false y la pelota empieza a moverse con su propia velocidad.

Colisión con la paleta

La colisión con la paleta funciona exactamente igual que en Pong. La única diferencia es que la paleta está abajo y solo nos importa el rebote desde arriba, no desde los lados.

function comprobarColisionPaleta() {
	const paletaY = ALTO - ALTO_PALETA - 10;
	if (
		pelota.x < paleta.x + ANCHO_PALETA &&
		pelota.x + TAMANO_PELOTA > paleta.x &&
		pelota.y + TAMANO_PELOTA > paletaY &&
		pelota.y < paletaY + ALTO_PALETA &&
		pelota.vy > 0
	) {
		pelota.y = paletaY - TAMANO_PELOTA;
		const centroPaleta = paleta.x + ANCHO_PALETA / 2;
		const centroPelota = pelota.x + TAMANO_PELOTA / 2;
		const offset = (centroPelota - centroPaleta) / (ANCHO_PALETA / 2);
		const velocidad = Math.sqrt(pelota.vx ** 2 + pelota.vy ** 2);
		const angulo = offset * (Math.PI / 3);
		pelota.vx = velocidad * Math.sin(angulo);
		pelota.vy = -velocidad * Math.cos(angulo);
	}
}

Aquí hago algo más sofisticado que en Pong. En lugar de cambiar vy simplemente, recalculo la dirección entera de la pelota usando trigonometría. La idea es que el ángulo de salida dependa de en qué punto de la paleta golpeó la pelota: si golpea en el centro, sale recta hacia arriba; si golpea en el extremo izquierdo, sale con un ángulo de hasta sesenta grados hacia la izquierda; si golpea en el extremo derecho, sale con sesenta grados hacia la derecha.

La constante Math.PI / 3 es sesenta grados expresados en radianes. Si quieres que el rango de ángulos sea más estrecho (rebotes más predecibles), reduce ese valor. Si lo quieres más amplio (rebotes más extremos), súbelo. He puesto sesenta grados porque es el clásico de los juegos arcade de la época y da control suficiente al jugador sin que la pelota pueda salir casi horizontal y volverse incontrolable.

Colisión con los ladrillos

Aquí está el corazón nuevo del juego respecto a Pong. La pelota tiene que colisionar contra todos los ladrillos vivos, y cuando golpea uno, hay que destruirlo y rebotar.

function comprobarColisionLadrillos() {
	for (const l of ladrillos) {
		if (!l.vivo) continue;
		if (
			pelota.x < l.x + ANCHO_LADRILLO &&
			pelota.x + TAMANO_PELOTA > l.x &&
			pelota.y < l.y + ALTO_LADRILLO &&
			pelota.y + TAMANO_PELOTA > l.y
		) {
			l.vivo = false;
			puntos += l.puntos;

			const centroPelota = {
				x: pelota.x + TAMANO_PELOTA / 2,
				y: pelota.y + TAMANO_PELOTA / 2,
			};
			const centroLadrillo = {
				x: l.x + ANCHO_LADRILLO / 2,
				y: l.y + ALTO_LADRILLO / 2,
			};
			const dx =
				Math.abs(centroPelota.x - centroLadrillo.x) - ANCHO_LADRILLO / 2;
			const dy =
				Math.abs(centroPelota.y - centroLadrillo.y) - ALTO_LADRILLO / 2;

			if (dx > dy) {
				pelota.vx = -pelota.vx;
			} else {
				pelota.vy = -pelota.vy;
			}
			return;
		}
	}
}

Lo bonito aquí es decidir si la pelota rebotó en un lateral o en la parte superior/inferior del ladrillo. Sin esa distinción, una pelota que viene en diagonal podría hacer rebotes raros que no se corresponden con la geometría real. La técnica que uso es comparar las distancias del centro de la pelota a los bordes del ladrillo en cada eje. Si la diferencia horizontal es mayor que la vertical, la pelota golpeó por el lateral (rebote horizontal). Si es al revés, golpeó por arriba o por abajo (rebote vertical). Es una heurística sencilla que funciona muy bien en la práctica para rectángulos de proporción razonable.

El return al final del bloque es importante: solo procesamos un ladrillo por fotograma. Sin él, una pelota muy rápida podría golpear dos ladrillos al mismo tiempo y rebotar dos veces, anulando el rebote y atravesando la pared. Con el return, garantizamos que el rebote es siempre limpio.

Mover la paleta

La paleta se controla con las flechas izquierda y derecha o con A y D. Misma lógica que en Pong, pero horizontal en lugar de vertical.

const teclas = { izquierda: false, derecha: false };

document.addEventListener("keydown", (e) => {
	if (e.key === "ArrowLeft" || e.key === "a" || e.key === "A")
		teclas.izquierda = true;
	if (e.key === "ArrowRight" || e.key === "d" || e.key === "D")
		teclas.derecha = true;
	if (e.key === " " && pegada) lanzarPelota();
});

document.addEventListener("keyup", (e) => {
	if (e.key === "ArrowLeft" || e.key === "a" || e.key === "A")
		teclas.izquierda = false;
	if (e.key === "ArrowRight" || e.key === "d" || e.key === "D")
		teclas.derecha = false;
});

function moverPaleta() {
	const VELOCIDAD = 7;
	if (teclas.izquierda) paleta.x -= VELOCIDAD;
	if (teclas.derecha) paleta.x += VELOCIDAD;
	paleta.x = Math.max(0, Math.min(ANCHO - ANCHO_PALETA, paleta.x));
}

function lanzarPelota() {
	pegada = false;
	pelota.vx = (Math.random() - 0.5) * 4;
	pelota.vy = -5;
}

La función lanzarPelota despega la pelota de la paleta y le da una velocidad inicial. La velocidad horizontal es ligeramente aleatoria para que cada saque sea distinto, y la velocidad vertical es siempre hacia arriba.

Perder y reiniciar

Cuando la pelota se sale por debajo, el jugador pierde una vida. Si todavía le quedan vidas, la pelota vuelve a pegarse a la paleta para empezar de nuevo. Si no, fin del juego.

function perderVida() {
	vidas--;
	pegada = true;
	pelota.vx = 0;
	pelota.vy = 0;
	if (vidas <= 0) {
		setTimeout(() => alert(`Fin del juego. Puntos: ${puntos}`), 100);
		reiniciarJuego();
	}
}

function reiniciarJuego() {
	puntos = 0;
	vidas = 3;
	pegada = true;
	generarLadrillos();
}

También hay que comprobar si el jugador ha ganado, lo que ocurre cuando todos los ladrillos están muertos. Esto se mira en cada fotograma después del bucle de colisiones.

function comprobarVictoria() {
	if (ladrillos.every((l) => !l.vivo)) {
		setTimeout(() => alert(`¡Nivel completado! Puntos: ${puntos}`), 100);
		reiniciarJuego();
	}
}

Dibujar todo

La función de dibujado limpia el canvas y pinta la paleta, la pelota y todos los ladrillos vivos.

const lienzo = document.getElementById("lienzo");
const ctx = lienzo.getContext("2d");

function dibujar() {
	ctx.fillStyle = "#0f1115";
	ctx.fillRect(0, 0, ANCHO, ALTO);

	for (const l of ladrillos) {
		if (!l.vivo) continue;
		ctx.fillStyle = l.color;
		ctx.fillRect(l.x, l.y, ANCHO_LADRILLO, ALTO_LADRILLO);
	}

	ctx.fillStyle = "#e8e8e8";
	ctx.fillRect(paleta.x, ALTO - ALTO_PALETA - 10, ANCHO_PALETA, ALTO_PALETA);
	ctx.fillRect(pelota.x, pelota.y, TAMANO_PELOTA, TAMANO_PELOTA);
}

El bucle principal

Igual que en Pong, usamos requestAnimationFrame para sincronizar el bucle con la frecuencia de refresco de la pantalla.

function bucle() {
	moverPaleta();
	actualizarPelota();
	comprobarColisionPaleta();
	comprobarColisionLadrillos();
	comprobarVictoria();
	dibujar();
	document.getElementById("puntos").textContent = puntos;
	document.getElementById("vidas").textContent = vidas;
	requestAnimationFrame(bucle);
}

generarLadrillos();
bucle();

Y con esto el juego ya funciona. Tienes una paleta que se mueve, una pelota que rebota contra los bordes y los ladrillos, una pared que se va destruyendo y un sistema de vidas. Todo en menos de doscientas líneas de código, que es bastante poco para un juego con esta complejidad aparente.

Cosas que se pueden añadir

Las posibilidades a partir de aquí son enormes. Power-ups que aparecen al destruir ciertos ladrillos: una paleta más grande, una segunda pelota, un láser que dispara desde la paleta. Ladrillos especiales que necesitan dos golpes para romperse. Niveles diseñados a mano con patrones de ladrillos en forma de letra, dibujo o paisaje. Aceleración progresiva de la pelota a medida que se rompen más ladrillos. Sonido al rebotar y al destruir. Una pantalla de inicio. Un sistema de vidas extra cada cierta puntuación. Y, por supuesto, cuando se completa un nivel pasar al siguiente con una pared distinta en lugar de reiniciar.

La mayoría de estas mejoras son fáciles de añadir sobre el esqueleto que tenemos. Los power-ups, por ejemplo, son simplemente otro array de objetos que caen desde los ladrillos destruidos y modifican el estado de la paleta o la pelota cuando son recogidos. Los niveles son matrices que reemplazan la generación uniforme actual. La aceleración progresiva es un multiplicador que se aplica a la velocidad de la pelota cada cierto número de ladrillos destruidos.

El prototipo funcional

Aquí abajo dejo el juego completo y funcionando, con cinco filas de ladrillos de colores, control con teclado y soporte táctil para móvil (la paleta sigue al dedo deslizado en la mitad inferior de la pantalla), aceleración progresiva, niveles infinitos y una estética cuidada. Está todo aislado bajo un id propio para que no afecte al resto del blog.

Otros tutoriales de la serie: 2048 · Pong · Serpiente · Parejas.

El IBAN —International Bank Account Number— es el estándar europeo (y de bastantes países más) para identificar cuentas bancarias de forma inequívoca. Y lo interesante es que tiene un mecanismo de validación matemática incorporado, lo que significa que podemos saber, con certeza, si un IBAN dado es formalmente correcto antes de enviar nada a ningún servidor. No si la cuenta existe, ojo, pero sí si el número tiene sentido.

La estructura del IBAN

Un IBAN tiene siempre la misma anatomía. Empieza con dos letras que identifican el país según la norma ISO 3166-1, seguidas de dos dígitos de control —el corazón del mecanismo de validación— y a continuación el BBAN (Basic Bank Account Number), que es el número de cuenta propio del sistema bancario nacional y cuya estructura varía según el país.

El IBAN español, por ejemplo, tiene 24 caracteres en total: ES + 2 dígitos de control + 4 dígitos de código de banco + 4 de código de sucursal + 2 dígitos de control interno + 10 dígitos de número de cuenta. Alemania usa 22 caracteres, Francia 27, Malta 31. No hay una longitud universal, y eso importa a la hora de validar.

El algoritmo: mover, convertir, dividir

El método de validación es elegante en su sencillez. Se llama MOD-97-10 y funciona en tres pasos.

Primero, se mueven los cuatro primeros caracteres del IBAN al final. Si tenemos ES9121000418450200051332, lo transformamos en 21000418450200051332ES91. Segundo, cada letra se sustituye por su valor numérico según el estándar: A = 10, B = 11, y así hasta Z = 35. Con esa sustitución, el IBAN completo se convierte en una cadena de dígitos, potencialmente muy larga. Tercero, se calcula el resto de dividir ese número entre 97. Si el resultado es 1, el IBAN es válido.

function mod97(numStr) {
	let resto = 0;
	for (const digito of numStr) {
		resto = (resto * 10 + parseInt(digito)) % 97;
	}
	return resto;
}

function validarIBAN(raw) {
	const iban = raw
		.trim()
		.toUpperCase()
		.replace(/[\s\-]/g, "");

	if (!/^[A-Z]{2}\d{2}[A-Z0-9]{4,}$/.test(iban)) {
		return { valido: false, error: "formato" };
	}

	const reordenado = iban.substring(4) + iban.substring(0, 4);
	const numerico = reordenado.replace(/[A-Z]/g, (c) =>
		(c.charCodeAt(0) - 55).toString(),
	);

	return { valido: mod97(numerico) === 1, pais: iban.substring(0, 2) };
}

El problema de los números enormes

Un IBAN puede convertirse en una cadena de hasta 34 dígitos. Eso es un número que desborda con holgura la precisión de un Number estándar en JavaScript, que empieza a perder exactitud con enteros por encima de Number.MAX_SAFE_INTEGER (2^53 − 1). Si intentáramos hacer parseInt(numerico) % 97 directamente con un número tan grande, el resultado sería incorrecto.

Hay dos soluciones. La primera es la función mod97 que aparece en el código anterior: procesa la cadena dígito a dígito, acumulando el resto parcial en cada paso. Es la opción más compatible, funciona en cualquier entorno y no requiere nada especial. La segunda es usar BigInt, disponible en todos los navegadores modernos desde hace años:

const valido = BigInt(numerico) % 97n === 1n;

Ambas opciones son correctas. La primera es más pedagógica y compatible; la segunda es más compacta. Quédate con la que mejor encaje en tu contexto.

Validar la longitud según el país

El formato mínimo descrito hasta aquí detecta IBANs con letras donde no toca o con una estructura radicalmente incorrecta, pero no avisa si alguien introduce un IBAN español de 22 caracteres cuando debería tener 24. Para eso, conviene incluir una tabla de longitudes por país.

const LONGITUDES_IBAN = {
	AL: 28,
	AD: 24,
	AT: 20,
	BE: 16,
	BA: 20,
	BR: 29,
	BG: 22,
	HR: 21,
	CY: 28,
	CZ: 24,
	DK: 18,
	EE: 20,
	FI: 18,
	FR: 27,
	DE: 22,
	GI: 23,
	GR: 27,
	HU: 28,
	IS: 26,
	IE: 22,
	IT: 27,
	LV: 21,
	LI: 21,
	LT: 20,
	LU: 20,
	MT: 31,
	MC: 27,
	NL: 18,
	NO: 15,
	PL: 28,
	PT: 25,
	RO: 24,
	SM: 27,
	SK: 24,
	SI: 19,
	ES: 24,
	SE: 24,
	CH: 21,
	GB: 22,
};

Con esta tabla, la función de validación puede ofrecer mensajes de error mucho más útiles: no solo «IBAN incorrecto», sino «este IBAN tiene 22 caracteres y los IBANs españoles tienen 24». Esa diferencia entre el error genérico y el error específico puede ahorrar al usuario varios intentos de frustración.

La función completa, con mensajes detallados

Juntando todo —limpieza de entrada, validación de formato, comprobación de longitud y algoritmo MOD-97— queda algo así:

const LONGITUDES_IBAN = {
	ES: 24,
	DE: 22,
	FR: 27,
	GB: 22,
	IT: 27,
	PT: 25,
	NL: 18,
	BE: 16 /* ... */,
};

function mod97(numStr) {
	let resto = 0;
	for (const d of numStr) resto = (resto * 10 + parseInt(d)) % 97;
	return resto;
}

function validarIBAN(raw) {
	const iban = raw
		.trim()
		.toUpperCase()
		.replace(/[\s\-]/g, "");
	const pais = iban.substring(0, 2);

	if (!/^[A-Z]{2}\d{2}[A-Z0-9]{4,}$/.test(iban)) {
		return { valido: false, mensaje: "Formato no reconocido" };
	}

	const longEsperada = LONGITUDES_IBAN[pais];
	if (longEsperada && iban.length !== longEsperada) {
		return {
			valido: false,
			mensaje: `El IBAN de ${pais} debe tener ${longEsperada} caracteres (este tiene ${iban.length})`,
		};
	}

	const numerico = (iban.substring(4) + iban.substring(0, 4)).replace(
		/[A-Z]/g,
		(c) => (c.charCodeAt(0) - 55).toString(),
	);

	return {
		valido: mod97(numerico) === 1,
		pais,
		control: iban.substring(2, 4),
		bban: iban.substring(4),
		mensaje:
			mod97(numerico) === 1
				? "IBAN válido"
				: "Los dígitos de control no son correctos",
	};
}

El replace(/[\s\-]/g, '') al inicio merece una mención: los IBANs se presentan habitualmente agrupados en bloques de cuatro caracteres separados por espacios (ES91 2100 0418...), y algunos usuarios los copian así directamente. Limpiar esos espacios antes de procesar evita rechazos innecesarios y mejora la experiencia sin ningún coste.

Integración en un formulario con feedback en tiempo real

La validación funciona mejor cuando acompaña al usuario mientras escribe, no cuando le sorprende al pulsar «Enviar». Un pequeño listener sobre el campo es suficiente para dar ese feedback progresivo:

const campo = document.getElementById("iban");
const aviso = document.getElementById("aviso-iban");

campo.addEventListener("input", () => {
	const valor = campo.value;

	if (!valor.trim()) {
		aviso.textContent = "";
		campo.removeAttribute("aria-invalid");
		return;
	}

	const resultado = validarIBAN(valor);
	aviso.textContent = resultado.mensaje;
	aviso.className = resultado.valido ? "aviso ok" : "aviso error";
	campo.setAttribute("aria-invalid", resultado.valido ? "false" : "true");
});

Un detalle que vale la pena añadir: si tu formulario va a recibir IBANs de muchos países, muestra al usuario la longitud esperada o un ejemplo en el campo. Un placeholder como ES91 2100 0418 4502 0005 1332 ayuda más que un campo vacío con una etiqueta que solo dice «IBAN».

Lo que esta validación no puede decirte

Conviene ser honesto sobre los límites del algoritmo. Un IBAN puede pasar la validación MOD-97 y aun así no existir como cuenta real —un número inventado que, por azar matemático, cumple el criterio. Esto es estadísticamente poco probable (la probabilidad de que un IBAN aleatorio sea válido es aproximadamente 1 entre 97), pero no imposible.

La validación matemática descarta errores tipográficos, transposiciones de dígitos y formatos incorrectos con gran fiabilidad. Para verificar que una cuenta es real y está activa, habría que recurrir a servicios externos, y eso ya es otro artículo.

A continuación puedes encontrar un validador funcional con todo lo que hemos descrito: detección del país, comprobación de longitud, algoritmo MOD-97 y desglose del resultado.

Lo que no sabía entonces, o sabía solo vagamente, es que esos juegos los habían hecho españoles. Que detrás de aquellas carátulas con ilustraciones que parecían sacadas de una novela de fantasía había equipos pequeñísimos, a veces de dos o tres personas, en pisos de Madrid, programando en ensamblador para un ordenador de 8 bits con 48 kilobytes de RAM. Y que algunos de esos juegos —los mismos que yo cargaba en Bilbao— se estaban vendiendo en tiendas de Londres.

Por qué España y por qué entonces

La penetración de ordenadores domésticos en España a principios de los ochenta fue, por razones de precio y distribución, especialmente alta para el ZX Spectrum. Sinclair había encontrado aquí un mercado hambriento, y con el Spectrum llegó todo lo demás: las tiendas de software, las revistas especializadas, la comunidad de aficionados.

MicroHobby, la publicación de referencia para los usuarios del Spectrum en España, llegó a tiradas de decenas de miles de ejemplares. Micromanía cubría el territorio más amplio de la informática personal. El ecosistema editorial era real y sostenido, y eso creó el caldo de cultivo para que hubiera programadores que quisieran publicar y un público dispuesto a comprar.

El otro factor fue el bajo coste de entrada. Programar un juego para 8 bits no requería un estudio, ni un equipo de cincuenta personas, ni un presupuesto de producción. Requería tiempo, conocimientos de ensamblador y, en los mejores casos, una idea que valiera la pena. Esas condiciones favorecieron a los emprendedores jóvenes que no tenían capital pero sí tenían talento y muchas horas disponibles.

Dinamic y el oficio de construir desde la nada

Dinamic Software nació de tres hermanos: Víctor, Nacho y Pablo Ruiz. Empezaron a principios de los ochenta con juegos modestos y fueron ganando terreno hasta convertirse en la empresa de software de entretenimiento más importante que ha tenido este país. Abu Simbel Profanation —1985, Spectrum— fue uno de sus primeros grandes éxitos: un juego de plataformas con una dificultad implacable y una precisión técnica que se notaba en cada pantalla. Hundra llegó dos años después, con una protagonista que era una guerrera de la fantasía épica en un momento en que los videojuegos con personajes femeninos principales eran casi inexistentes.

Las carátulas de Dinamic eran otro mundo. Ilustraciones de fantasía y ciencia ficción con una energía visual que no tenía nada que envidiar a las portadas de las novelas americanas del género. En una época en que el packaging era muchas veces la única seña de identidad de un producto que luego ocupaba 48K de memoria, Dinamic entendió que la primera impresión contaba y la cuidó con consistencia.

Game Over, Army Moves, Freddy Hardest, After the War. Juego tras juego, la empresa fue construyendo un catálogo que se reconocía de un vistazo y que sus compradores esperaban con la misma anticipación con que hoy se espera un triple A.

Opera Soft y el argumento definitivo

Si Dinamic representa el músculo comercial de aquella industria, Opera Soft tiene el argumento más sólido para quien quiera hablar de excelencia sin matices. La Abadía del Crimen, publicado en 1987, es una de las obras más extraordinarias que ha producido el software de entretenimiento español en cualquier época.

Paco Menéndez construyó un juego isométrico en 3D —en un Spectrum con 48K— inspirado directamente en El nombre de la rosa de Umberto Eco. No era una adaptación con licencia, sino una reinterpretación libre que tomaba el monasterio medieval, el monje detective y la atmósfera del libro y los convertía en mecánicas de juego. La arquitectura del edificio era coherente y navegable. Los personajes tenían rutinas propias. El argumento tenía peso.

Pocos juegos de esa generación resisten el análisis de hoy como lo resiste La Abadía. Es el tipo de obra que dice algo sobre la persona que la hizo: alguien con algo concreto que expresar que encontró la manera de expresarlo dentro de unas limitaciones técnicas brutales.

El dato que cambia la perspectiva

Los juegos de Dinamic se vendían en el Reino Unido. Aparecían reseñados en Crash y Your Sinclair, que eran las publicaciones de referencia mundial para el Spectrum. No como curiosidades exóticas: como juegos que competían en el mismo mercado que los títulos británicos y americanos y que a veces los superaban en las valoraciones.

España no era un mercado periférico que consumía lo que se producía en otros sitios. Era, junto con el Reino Unido, uno de los dos países europeos con una industria doméstica de desarrollo real para los ordenadores de 8 bits. Eso no lo sabe casi nadie hoy. Valdría la pena que lo supiera más gente.

El precipicio de los 16 bits

El problema llegó con la transición: el Amiga 500, el Atari ST, y poco después el PC. Los equipos de dos o tres personas que habían bastado para el Spectrum ya no eran suficientes. Los presupuestos de producción se dispararon, los tiempos de desarrollo se alargaron y la competencia internacional se profesionalizó de golpe.

Algunas de esas empresas lo intentaron. Dinamic publicó títulos para Amiga y PC. Pero el salto era enorme, y las estructuras que habían funcionado perfectamente para los 8 bits no escalaban con facilidad. A principios de los noventa, la mayor parte de aquella generación de estudios había desaparecido o se había transformado en otra cosa.

Lo que queda

Queda la conciencia, para quien quiera buscarla, de que hubo aquí una industria creativa real, construida desde cero por gente joven con pocos recursos y mucho talento, que llegó a mercados internacionales en un momento en que eso no era fácil para ningún producto cultural español.

Y quedan los juegos. El Abu Simbel en casete que tardaba tres minutos en cargar. El Hundra con su protagonista imposible. La Abadía, que sigue siendo visitable hoy y sigue funcionando como experiencia.

No está mal para un país que, según el relato oficial, llegó tarde a la tecnología.

El círculo cromático, o por qué algunos colores se llevan bien

La teoría del color lleva siglos siendo estudiada, desde los primeros trabajos de Newton descomponiendo la luz blanca hasta el círculo de Itten que se enseña en cualquier escuela de diseño. La idea central es siempre la misma: los colores no son entidades aisladas, sino que existen en relación unos con otros, y esas relaciones tienen una geometría.

El círculo cromático organiza los colores por su tono —lo que en inglés se llama hue— en un espacio circular de 360 grados. Los colores primarios de la luz (rojo, verde, azul) están separados a 120 grados entre sí. Entre ellos se distribuyen los intermedios: amarillos, cians, magentas, naranjas. La clave es que cuando hablamos de armonía cromática, estamos hablando de ángulos: qué ocurre si tomamos el color opuesto, o los que están a un tercio del círculo, o los vecinos inmediatos.

Esta geometría es lo que convierte un problema de "¿qué color combina con este?" en algo calculable con una suma simple. Si tu color está en la posición 30 grados del círculo, su complementario está exactamente en 30 + 180 = 210 grados. Su triádico, a 30 + 120 = 150 y a 30 + 240 = 270. No hay magia, solo rotación.

Los cinco tipos de armonía que vale la pena conocer

La armonía complementaria es la más elemental: el color opuesto en el círculo, a 180 grados. Produce el contraste más fuerte posible y es lo que hace que un cartel naranja sobre azul resulte tan llamativo. Úsala cuando quieras impacto; evítala cuando quieras sutileza.

El complementario dividido es una versión más refinada: en lugar de ir directamente al opuesto, tomas los dos colores que flanquean ese opuesto, a ±150 grados del original. El resultado es casi igual de llamativo pero bastante menos agresivo, y tienes tres colores en lugar de dos.

La armonía triádica coloca tres colores a 120 grados entre sí, formando un triángulo equilátero dentro del círculo. Es vibrante y equilibrada. Es la favorita de muchos diseñadores de interfaces porque ninguno de los tres colores domina demasiado sobre los otros.

La armonía análoga toma los vecinos inmediatos del color base, normalmente a ±30 grados. El resultado es la más tranquila y natural de todas —piensa en los degradados de una puesta de sol, o en los verdes de un bosque. Los colores análogos son siempre seguros y agradables, pero pueden volverse aburridos si no hay suficiente variación de luminosidad o saturación.

Por último, la tetrádica —también llamada cuadrada— coloca cuatro colores a 90 grados entre sí. Es la más compleja de manejar porque da mucho color, pero en manos de alguien que sabe lo que hace produce resultados muy ricos.

HSL: el espacio de color que hace todo esto natural

Para implementar estas armonías en código, lo primero es elegir el sistema de representación del color adecuado. El formato hexadecimal que usamos en CSS (#3B82F6) es cómodo para escribir pero inútil para calcular. El RGB tampoco ayuda mucho. Lo que necesitamos es el sistema HSL: Hue (tono), Saturation (saturación), Lightness (luminosidad).

En HSL, el tono es exactamente el ángulo en el círculo cromático, un valor entre 0 y 360. La saturación va de 0% (gris neutro) a 100% (color puro). La luminosidad va de 0% (negro) a 100% (blanco), con el 50% como punto donde el color es más vívido. Esto significa que calcular el complementario de un color HSL es tan directo como sumar 180 al valor H:

function complementario(h, s, l) {
	return [(h + 180) % 360, s, l];
}

Y el triádico, añadir 120 y 240:

function triadica(h, s, l) {
	return [
		[h, s, l],
		[(h + 120) % 360, s, l],
		[(h + 240) % 360, s, l],
	];
}

El operador % 360 asegura que si el ángulo supera 360, vuelve a empezar desde cero. En JavaScript, hay que tener cuidado con los negativos —si sumamos -30 a un hue de 10, obtenemos -20, que no tiene sentido en el círculo— así que conviene usar ((h + offset) % 360 + 360) % 360 para estar seguros.

Convertir entre formatos: de hex a HSL y vuelta

El problema práctico es que los usuarios (y los selectores de color del navegador) trabajan con hexadecimal, pero nuestros cálculos necesitan HSL. Así que la herramienta necesita dos conversiones: hexToHsl y hslToHex.

La conversión de hex a HSL funciona así: primero extraemos los canales R, G y B del string hexadecimal, los normalizamos a un rango de 0 a 1, y luego calculamos el tono, la saturación y la luminosidad con unas pocas operaciones aritméticas. El tono depende de cuál de los tres canales es el máximo, y se expresa como un ángulo en el círculo.

function hexToHsl(hex) {
	const r = parseInt(hex.slice(1, 3), 16) / 255;
	const g = parseInt(hex.slice(3, 5), 16) / 255;
	const b = parseInt(hex.slice(5, 7), 16) / 255;

	const max = Math.max(r, g, b);
	const min = Math.min(r, g, b);
	const l = (max + min) / 2;
	let h = 0,
		s = 0;

	if (max !== min) {
		const d = max - min;
		s = l > 0.5 ? d / (2 - max - min) : d / (max + min);
		if (max === r) h = ((g - b) / d + (g < b ? 6 : 0)) / 6;
		else if (max === g) h = ((b - r) / d + 2) / 6;
		else h = ((r - g) / d + 4) / 6;
	}

	return [Math.round(h * 360), Math.round(s * 100), Math.round(l * 100)];
}

La conversión inversa, de HSL a hex, es algo más compleja matemáticamente pero sigue el mismo principio. Se reconstruyen los canales RGB a partir del tono, la saturación y la luminosidad, y luego se convierten a hexadecimal:

function hslToHex(h, s, l) {
	h = ((h % 360) + 360) % 360;
	s /= 100;
	l /= 100;
	const a = s * Math.min(l, 1 - l);
	const f = (n) => {
		const k = (n + h / 30) % 12;
		const c = l - a * Math.max(-1, Math.min(k - 3, 9 - k, 1));
		return Math.round(255 * c)
			.toString(16)
			.padStart(2, "0");
	};
	return "#" + f(0) + f(8) + f(4);
}

Con estas dos funciones, el flujo completo es: recibir un color en hex → convertir a HSL → aplicar los offsets angulares → convertir cada resultado de vuelta a hex → mostrar en pantalla.

La interfaz: selector de color, swatches y rueda visual

La parte visual de la herramienta se construye con HTML y CSS estándar, sin frameworks ni librerías externas. El selector de color usa el elemento nativo <input type="color">, que en los navegadores modernos abre un selector completo con soporte para cualquier color del espacio sRGB. Complementamos esto con un campo de texto donde el usuario puede escribir directamente el código hex, validando en tiempo real que tenga el formato correcto (# seguido de seis caracteres hexadecimales).

La rueda de color que aparece en la interfaz es un <canvas> de HTML5. Se dibuja recorriendo los 360 grados y pintando para cada ángulo un arco con un degradado radial que va del blanco en el centro al color puro del borde. El resultado es una representación visual del espacio HSL con saturación y luminosidad fijas. Sobre esta rueda se colocan puntos que marcan la posición del color base y su complementario.

Los swatches de cada armonía son simples <div> con su background-color calculado. Al hacer clic sobre cualquiera de ellos, se copia el hex al portapapeles usando la API navigator.clipboard.writeText(). Una pequeña notificación emergente confirma la acción.

Lo que me llevé de todo esto

Construir esta herramienta me recordó que detrás de muchas decisiones de diseño que parecen intuitivas hay estructuras matemáticas bastante elegantes. El círculo cromático no es una metáfora bonita: es un espacio vectorial donde la armonía es literalmente una cuestión de geometría. Puedes intuir que el naranja y el azul combinan bien, o puedes saber que están a 180 grados entre sí en un espacio de 360, y que eso maximiza el contraste perceptivo entre dos tonos.

El código completo de la herramienta está disponible en esta misma página para que puedas usarla directamente, o coger las funciones de conversión y adaptarlas a tus propios proyectos. No hay dependencias, no hay build step, no hay nada que instalar. Un archivo HTML y ya está.

He vuelto al texto esta semana después de mucho tiempo y me he llevado una sorpresa: lo recordaba a medias. Recordaba bien la parte que más me había impresionado en su momento —los hombres de Arcachón y su cofradía silenciosa— y había olvidado todo lo demás, que es prácticamente la mitad del cuento. Releerlo entero ahora ha sido como descubrirlo otra vez. Y como me ha encantado por segunda vez, viene aquí.

El planteamiento, que ya te coloca de entrada

El relato empieza con una frase que es directamente una bofetada: cuando los venusianos vuelvan a la Tierra, el mundo comprenderá por qué Jesucristo no rió jamás. Así, sin preámbulo. Y a partir de ahí Gripari se pone a contarte el futuro de la humanidad como si ya lo hubiera vivido. Todo el cuento está escrito en futuro, no en pasado ni en presente, lo cual es bastante raro y le da un aire profético de los que dejan huella. Hacia el final del relato te explica de pasada que un equipo de médiums diplomados ha previsto la historia. Cuando uno termina y vuelve al principio, descubre que la frase de apertura ya contenía todo el cuento. Solo que entonces no podías saberlo.

El argumento, contado a grandes rasgos: en 1972 los venusianos llegan a la Tierra, físicamente idénticos a Jesucristo, y aterrizan justo a tiempo de evitar la Tercera Guerra Mundial entre los tres imperios del momento. A cambio imponen un gobierno planetario único y declaran el socialismo filosofía universal obligatoria. La Tierra se reorganiza en ocho repúblicas étnicamente puras —con deportaciones masivas para conseguirlo— y el mundo entero pasa a estar gobernado desde la Luna por una octarquía que colabora estrechamente con los venusianos. Hasta aquí ya tienes ciencia ficción política para parar un tren.

Pero lo bueno viene después.

Cuando el sexo pasa a ser propiedad del Estado

En este nuevo orden mundial, las cosas íntimas se van regulando poco a poco. Primero se abole el matrimonio. Luego se prohíbe la unión libre. Después aparece un invento llamado el Automacon, una máquina paregórica de pago propiedad del Estado, que canaliza la satisfacción sexual de manera ordenada y contable. Y en 1999, cualquier coito entre individuos de sexos diferentes pasa a estar castigado con reclusión perpetua para los dos. Sí, los dos.

Hay una frase del cuento que resume toda la lógica del sistema y que es de las cosas más afiladas que recuerdo haber leído. Es el artículo 127 de la Carta Mundial del Socialismo: todo deseo cuya satisfacción no proporcione dinero al Estado no es más que un vicio. Léela despacio. Y luego léela otra vez. Porque ahí dentro hay algo que da bastante miedo.

Eso lo escribió Gripari en 1972, fíjate. Cuando todavía existía la URSS, cuando la Guerra Fría estaba en su apogeo, cuando la idea de un gobierno mundial sonaba a delirio de novela. Hoy, leyéndolo en 2026, esa frase sigue funcionando perfectamente. Solo hay que cambiar la palabra Estado por la que más rabia te dé: plataforma, algoritmo, suscripción, lo que sea. La idea de fondo es la misma y se ha vuelto, si acaso, más actual.

Y entonces aparece el microbio rosa

En medio de toda esa pesadilla burocrática, ocurre algo que nadie había previsto. Hacia 1987, las aguas de la bahía de Arcachón empiezan a cambiar de color. Se van volviendo poco a poco rosadas, espesas, opacas, ligeramente viscosas. Cuando los científicos las analizan al microscopio descubren que están saturadas de una bacteria nueva, una mutación del esperma venusiano que se ha adaptado a la vida marina. La bautizan Venus Marítima, aunque pronto la gente la llamará simplemente el microbio rosa.

Las autoridades dudan si destruirla o dejarla vivir. Al final la dejan vivir porque parece inofensiva, está confinada a la bahía, y resulta que constituye un alimento extraordinario para las ostras de la zona, cuya producción se dispara. Una decisión razonable. Una decisión, también, que el régimen va a lamentar muchísimo en los años siguientes. Porque lo que las autoridades no saben todavía es que ese microbio se alimenta exclusivamente de esperma de mamíferos, y que tiene una especie de premonición de la sensualidad masculina que le permite ofrecer al macho humano una experiencia infinitamente superior al Automacon estatal. Y, lo más imperdonable de todo desde el punto de vista del régimen, gratuita.

El secreto mejor guardado del mundo

Y aquí viene la parte que me dejó marcado cuando leí el cuento por primera vez y que sigue pareciéndome la más extraordinaria. Durante quince años, de 1990 a 2005, los hombres de Eurasia entera viajan a Arcachón en cuanto pueden. Trabajadores rusos pidiendo vacaciones en las Landas, gente que hace el viaje desde Vladivostok, ancianos, adolescentes, adultos. Todos van. Todos se bañan en aquella agua rosada y tibia. Y nadie dice nada.

No estalla el escándalo, no se nombra el secreto, no se hace ni siquiera alusión. Adolescentes, adultos, ancianos, todo el mundo calla. Hay un párrafo en el cuento donde Gripari subraya que esa discreción colectiva supone una facultad de disimulo no solamente frente al poder, sino también frente a la población femenina, que tiene visos de prodigio. Y luego añade, con la mala leche que le sale natural, que una discreción así solo es posible bajo régimen socialista.

Aparecen señales raras, claro. Los hombres se bañan menos rato que las mujeres, ciertos individuos van en grupos al caer la noche, se forma un amago de secta llamada los adoradores del mar que las autoridades disuelven aplicando la ley contra ideologías no marxistas. Pero ni siquiera durante el proceso judicial los acusados hablan. Y los jueces, esto es magistral, se guardarán de hacerles preguntas demasiado precisas. Es decir: no solo callan los gobernados. También callan los gobernantes, porque saben que conocer ciertas cosas les obligaría a actuar contra placeres que, en el fondo, también se reservan para sí mismos.

El perrito que lo arruina todo

Como casi siempre pasa con los grandes secretos, el final no llega por una traición ni por una investigación policial. Llega por un accidente menor. Una turista rusa, presentada en el cuento como la Dama del Perrito, fuerza a su caniche Polkan a bañarse en Arcachón. El perro, ajeno a las cautelas humanas que habían sostenido el secreto durante tres lustros, se niega a salir del agua. La escena que Gripari describe es comiquísima y desoladora a la vez: el caniche con el trasero metido en la bahía, los riñones moviéndose espasmódicamente, los ojos en blanco, la lengua fuera, gruñendo a su dueña cuando esta intenta sacarlo del agua.

A partir de ahí todo se precipita. La dama escribe a un amigo escritor, este viaja a Arcachón a comprobarlo personalmente, redacta un informe oficial que se publica en todas las lenguas del mundo, y el régimen pone en marcha la maquinaria de la propaganda. Al microbio rosa lo bautizan con nombres burlescos en cada idioma —los ingleses lo llaman sea-whore, los alemanes Wassarhure, los rusos Vodobliad— para intentar quitarle dignidad. Los científicos desarrollan un antibiótico específico, lo lanzan en dosis masivas a la bahía, y Venus Marítima desaparece para siempre. Las playas se desinfectan y se reabren al público.

El cuento termina con una sola frase que llevo intentando olvidar desde que la leí por primera vez y no consigo: tras este intermedio, la humanidad podrá dormirse de nuevo, para largos milenios, en el profundo aburrimiento de la era socialista. Telón.

Por qué me parece que el cuento sigue dando en el clavo

Me he pasado los últimos días pensando por qué este cuento, escrito hace más de cincuenta años por un autor casi desconocido, sigue resonando tan fuerte. Y creo que es por el artículo 127. Por esa frase del Estado y los deseos que no producen dinero. Porque el cuento, al final, no va de venusianos ni de microbios rosa. Va de cómo cualquier sistema, cuando logra suficiente poder, intenta capturar las formas en que las personas obtienen placer, y de cómo las cosas que se escapan de esa captura terminan siendo perseguidas, ridiculizadas o exterminadas con antibiótico.

Gripari estaba pensando en la URSS, eso queda claro. Pero el mecanismo que describe no es exclusivo de aquel régimen. Cualquier sistema, en cuanto puede, intenta canalizar los placeres hacia formas que pueda contar, gravar o regular. Y cualquier sistema reacciona mal cuando descubre que existe un placer importante al que no puede meterle factura. Por eso este cuento de 1972 sigue pareciendo escrito ayer. La forma exterior es de los setenta, pero el motor de la historia funciona perfectamente con el combustible que le eches: comunismo, capitalismo de plataforma, moralismo de cualquier color. Lo único que no perdona el sistema, sea cual sea, es la felicidad gratuita.

Por qué conviene buscarlo

El libro se sigue editando en francés, dentro de un volumen que lleva el mismo título que el relato. En castellano hubo traducciones antiguas, de tirada limitada, y conviene buscarlas en librerías de viejo o en plataformas de segunda mano. Yo no recuerdo bien dónde encontré la mía, pero sé que no fue en una librería normal de las grandes. La búsqueda forma parte del juego. Hay algo bonito en perseguir un libro que no está en todos los escaparates, especialmente cuando lo que vas a encontrar dentro es justamente un cuento sobre un secreto compartido por pocos.

Si lo encuentras, léelo en una tarde tranquila. Cerca del mar a poder ser, aunque no es imprescindible. Y si después de leerlo te quedas pensando en el artículo 127 durante varios días, no te preocupes. A mí me lleva pasando desde la primera vez. Es lo que tienen ciertos cuentos. Una vez te entran, se quedan.

En este artículo voy a explicar cómo construirlo paso a paso en HTML, CSS y JavaScript, sin frameworks de ningún tipo, sin compiladores, sin servidores. Solo un archivo .html que abres en tu navegador y ya está. Al final del artículo dejo el prototipo entero funcionando para que puedas jugarlo y, si te apetece, ver el código fuente y trastear con él.

La idea general antes de tocar código

Antes de escribir una sola línea conviene tener claro qué es lo que vamos a construir. Un juego de la serpiente, en su esencia, consiste en una cuadrícula sobre la que se mueve una serpiente formada por segmentos cuadrados. La serpiente avanza automáticamente en una dirección, y el jugador puede cambiar esa dirección con las flechas del teclado. En la cuadrícula aparece una manzana en una posición aleatoria. Cuando la cabeza de la serpiente llega a la casilla donde está la manzana, esta desaparece, aparece otra en una nueva posición aleatoria y la serpiente crece un segmento. El juego termina si la serpiente choca contra los bordes del tablero o si se muerde a sí misma.

Conceptualmente, todo el juego se reduce a repetir el mismo paso una y otra vez, varias veces por segundo. Ese paso consiste en mover la serpiente una casilla en la dirección actual, comprobar si ha chocado contra algo, comprobar si ha comido la manzana y dibujar el resultado en pantalla. Esto se llama el bucle de juego, y es la pieza central de cualquier videojuego, desde el más sencillo hasta el más complejo. Si entiendes el bucle, entiendes la estructura. Lo demás son detalles.

El esqueleto HTML y CSS

Empezamos por la página web que va a contener el juego. Es lo más sencillo de todo: un archivo HTML con un elemento <canvas> donde vamos a dibujar, un par de elementos para mostrar la puntuación y un poco de CSS para que tenga un aspecto decente. El <canvas> es un elemento del HTML pensado precisamente para dibujar gráficos mediante JavaScript, y es la herramienta natural para hacer este tipo de juegos.

<!DOCTYPE html>
<html lang="es">
	<head>
		<meta charset="UTF-8" />
		<title>Snake</title>
		<style>
			body {
				display: flex;
				flex-direction: column;
				align-items: center;
				background: #1a1d24;
				color: #e8e8e8;
				font-family: system-ui, sans-serif;
			}
			canvas {
				background: #0f1115;
				border: 1px solid #2a2e36;
			}
		</style>
	</head>
	<body>
		<h1>Snake</h1>
		<div>Puntuación: <span id="puntuacion">0</span></div>
		<canvas id="lienzo" width="400" height="400"></canvas>
		<script>
			// aquí irá todo el código del juego
		</script>
	</body>
</html>

Con esto ya tenemos un canvas negro de 400 por 400 píxeles centrado en la pantalla. Vamos a dibujar dentro de él una cuadrícula imaginaria de 20 por 20 casillas, cada una de 20 píxeles. Esa cuadrícula no la vamos a dibujar realmente, pero sí la vamos a usar mentalmente como sistema de coordenadas para colocar la serpiente y la manzana.

El estado del juego

Lo siguiente es decidir qué información necesitamos guardar en cada momento para que el juego funcione. Esto se llama estado del juego, y para Snake es bastante sencillo. Necesitamos saber dónde está cada segmento de la serpiente, en qué dirección se mueve, dónde está la manzana, cuál es la puntuación y si la partida ha terminado. Lo representamos así:

const TAMANO_CASILLA = 20;
const COLUMNAS = 20;
const FILAS = 20;

let serpiente = [
	{ x: 10, y: 10 },
	{ x: 9, y: 10 },
	{ x: 8, y: 10 },
];
let direccion = { x: 1, y: 0 };
let manzana = { x: 5, y: 5 };
let puntuacion = 0;
let terminado = false;

La serpiente es un array de objetos donde cada objeto representa un segmento con sus coordenadas en la cuadrícula. El primer elemento del array es siempre la cabeza, y los siguientes el cuerpo. La dirección la representamos como un vector con valores x e y que pueden ser uno, menos uno o cero. Por ejemplo, { x: 1, y: 0 } significa que la serpiente se mueve hacia la derecha. Esto es muy cómodo porque permite calcular la siguiente posición de la cabeza simplemente sumando la dirección a la posición actual.

Mover la serpiente

Mover la serpiente es probablemente lo más bonito conceptualmente del juego, y lo más sencillo si lo piensas bien. La idea es la siguiente: en cada paso del juego, calculamos dónde estaría la nueva cabeza, la añadimos al principio del array, y quitamos el último elemento. Así la serpiente se desplaza una casilla sin tener que mover todos los segmentos uno a uno. Cuando la serpiente come una manzana, hacemos lo mismo pero sin quitar el último elemento, y así crece.

function paso() {
	if (terminado) return;

	const cabeza = serpiente[0];
	const nuevaCabeza = {
		x: cabeza.x + direccion.x,
		y: cabeza.y + direccion.y,
	};

	serpiente.unshift(nuevaCabeza);

	if (nuevaCabeza.x === manzana.x && nuevaCabeza.y === manzana.y) {
		puntuacion += 10;
		colocarManzana();
	} else {
		serpiente.pop();
	}
}

El método unshift añade un elemento al principio del array, y pop elimina el último. Ese pequeño truco evita tener que recorrer todos los segmentos en cada iteración, lo cual sería ineficiente si la serpiente fuera muy larga.

Detectar colisiones

Una serpiente que se mueve sin parar pero nunca pierde no es un juego. Necesitamos comprobar dos tipos de colisiones: contra los bordes del tablero y contra el propio cuerpo de la serpiente. Las dos comprobaciones se hacen justo antes de añadir la nueva cabeza al array.

const fueraDeLimites =
	nuevaCabeza.x < 0 ||
	nuevaCabeza.x >= COLUMNAS ||
	nuevaCabeza.y < 0 ||
	nuevaCabeza.y >= FILAS;

const seMuerde = serpiente.some(
	(s) => s.x === nuevaCabeza.x && s.y === nuevaCabeza.y,
);

if (fueraDeLimites || seMuerde) {
	terminado = true;
	return;
}

El método some recorre el array y devuelve true si encuentra al menos un elemento que cumpla la condición. En este caso, comprobamos si hay algún segmento de la serpiente cuya posición coincida con la nueva cabeza. Si lo hay, es que la serpiente se ha mordido a sí misma, y el juego termina.

Colocar la manzana

La manzana tiene que aparecer en una posición aleatoria del tablero, pero hay que tener cuidado: no puede aparecer encima de la serpiente, porque si lo hace el jugador la comería sin querer en cuanto se moviera. La forma más sencilla y robusta de evitarlo es generar posiciones aleatorias hasta dar con una que no esté ocupada.

function colocarManzana() {
	while (true) {
		const candidata = {
			x: Math.floor(Math.random() * COLUMNAS),
			y: Math.floor(Math.random() * FILAS),
		};
		const colisiona = serpiente.some(
			(s) => s.x === candidata.x && s.y === candidata.y,
		);
		if (!colisiona) {
			manzana = candidata;
			return;
		}
	}
}

Para una serpiente de tamaño normal este bucle termina prácticamente al primer intento, así que la ineficiencia teórica de tener un bucle infinito hipotético no es un problema real. Solo se notaría si la serpiente llegase a ocupar casi todo el tablero, en cuyo caso el jugador estaría a punto de ganar de todas formas.

Capturar el teclado

El jugador necesita poder cambiar la dirección de la serpiente. Esto se hace escuchando el evento keydown del documento y traduciendo cada tecla a un nuevo vector de dirección. Hay un detalle importante: no podemos permitir que la serpiente gire ciento ochenta grados de golpe, porque eso haría que la cabeza chocara inmediatamente con el segundo segmento del cuerpo. Así que filtramos las teclas que invierten exactamente la dirección actual.

document.addEventListener("keydown", (e) => {
	const teclas = {
		ArrowUp: { x: 0, y: -1 },
		ArrowDown: { x: 0, y: 1 },
		ArrowLeft: { x: -1, y: 0 },
		ArrowRight: { x: 1, y: 0 },
	};
	if (teclas[e.key]) {
		const nueva = teclas[e.key];
		if (nueva.x === -direccion.x && nueva.y === -direccion.y) return;
		direccion = nueva;
	}
});

En el prototipo final del artículo añado también las teclas WASD como alternativa a las flechas, una pausa con la barra espaciadora y soporte táctil con botones para que el juego funcione en móvil. Pero la lógica es exactamente la misma.

Dibujar en el canvas

Dibujar es la parte más visual y, por suerte, una de las más fáciles. El canvas tiene un objeto llamado contexto que ofrece métodos para dibujar rectángulos, líneas, texto y formas. Para Snake nos basta con dibujar rectángulos de colores. En cada iteración del juego limpiamos todo el canvas pintándolo del color de fondo y luego dibujamos la manzana y los segmentos de la serpiente en sus posiciones actuales.

const lienzo = document.getElementById("lienzo");
const ctx = lienzo.getContext("2d");

function dibujar() {
	ctx.fillStyle = "#0f1115";
	ctx.fillRect(0, 0, lienzo.width, lienzo.height);

	ctx.fillStyle = "#e74c3c";
	ctx.fillRect(
		manzana.x * TAMANO_CASILLA,
		manzana.y * TAMANO_CASILLA,
		TAMANO_CASILLA,
		TAMANO_CASILLA,
	);

	ctx.fillStyle = "#3ecf8e";
	serpiente.forEach((segmento) => {
		ctx.fillRect(
			segmento.x * TAMANO_CASILLA,
			segmento.y * TAMANO_CASILLA,
			TAMANO_CASILLA,
			TAMANO_CASILLA,
		);
	});
}

Las coordenadas de la serpiente y la manzana están en casillas, así que para convertirlas a píxeles basta con multiplicar por el tamaño de casilla. Si en algún momento quieres hacer la cuadrícula más grande o más pequeña, solo tienes que cambiar las constantes y el resto del código sigue funcionando sin tocar nada.

El bucle principal

Lo último que falta es repetir todo esto varias veces por segundo. La forma más sencilla es usar setInterval, que ejecuta una función cada cierto número de milisegundos. Para Snake, un intervalo de unos cien o ciento veinte milisegundos da una velocidad razonable. Más rápido se vuelve frustrante, más lento se vuelve aburrido.

function bucle() {
	paso();
	dibujar();
}

setInterval(bucle, 110);

Y con esto, el juego ya funciona. Tienes una serpiente que se mueve por el tablero, responde a las flechas del teclado, come manzanas y crece, choca con los bordes y consigo misma, y muestra una puntuación que va subiendo. Todo en menos de cien líneas de JavaScript si lo escribes apretado, y bastante por debajo de doscientas si lo organizas con calma como en el prototipo final.

Cosas que se pueden añadir si te apetece seguir

A partir de aquí, las posibilidades son enormes. Puedes añadir niveles que aumenten la velocidad cada cierta puntuación. Puedes añadir manzanas especiales que valgan más puntos pero aparezcan solo durante unos segundos. Puedes hacer que el tablero tenga obstáculos fijos. Puedes guardar el récord en localStorage para que persista entre sesiones. Puedes añadir sonidos. Puedes hacer que la serpiente atraviese los bordes y aparezca por el lado contrario, en lugar de morir. Puedes meter dos jugadores en el mismo tablero. Cualquier idea que se te ocurra cabe en este esqueleto.

Pero el verdadero valor de programar Snake no está en lo que se le añada después, sino en lo que se aprende construyéndolo. Cuando entiendes este código, entiendes la estructura básica de prácticamente cualquier juego clásico. El bucle, el estado, los eventos, el dibujado, las colisiones. Cambia los detalles y tienes un Tetris. Cambia otros y tienes un Pong. Cambia más cosas y tienes un Pac-Man. Todos comparten el mismo esqueleto que acabamos de construir aquí.

El prototipo funcional

Aquí abajo dejo el juego completo y funcionando. Es exactamente el mismo código que hemos ido viendo a lo largo del artículo, organizado un poco más limpio, con soporte para WASD y flechas, pausa con la barra espaciadora, controles táctiles para móvil, un récord que se mantiene durante la sesión y una pantalla de fin de partida con instrucciones para reiniciar.

Otros tutoriales de la serie: 2048 · Pong · Parejas · Ladrillos.

Y por si el nombre no fuera suficientemente desafortunado por sí solo, la campaña de Kickstarter asociada al lanzamiento —que alcanzó su objetivo de financiación en un solo día— acaba de ser cancelada, alegando problemas de entrega de correo electrónico. No es el tipo de estabilidad que inspira confianza.

El patrón conocido

Zach Leatherman, creador y mantenedor de Eleventy, ha insistido en que el proyecto sigue siendo código abierto, que la compatibilidad con el ecosistema actual está garantizada y que Build Awesome Pro no será un requisito para usar la herramienta. Le creo. Pero el patrón es conocido: Font Awesome siguió exactamente el mismo camino con Web Awesome (antes Shoelace), convirtiendo un proyecto comunitario en un producto freemium con capa de pago.

El argumento de que "la versión gratuita nunca desaparecerá" puede ser cierto, pero cambia inevitablemente la naturaleza del proyecto y sus prioridades. Cuando hay una versión de pago, los recursos de desarrollo se dirigen hacia las funcionalidades que justifican el precio. La versión gratuita se mantiene, pero deja de ser el foco.

Para quienes llevamos años en el nicho de los generadores estáticos precisamente porque nos alejaban de esa dinámica —porque 11ty era un proyecto de una sola persona, sin inversores, sin agenda comercial, con una comunidad que construía por placer— la transformación supone un punto de inflexión. No hace falta abandonar el barco hoy mismo, pero sí tiene sentido empezar a mirar el horizonte.

Lo que busco en un generador estático

Antes de mirar alternativas, conviene definir el punto de partida. No todo el mundo necesita lo mismo.

Hugo es extraordinariamente rápido, pero su sistema de plantillas en Go tiene una curva de aprendizaje pronunciada y resulta árido para quienes venimos de Nunjucks o Liquid. Astro es potente y moderno, pero arrastra una complejidad y una orientación hacia el componente JavaScript que lo aleja bastante de la filosofía que muchos valoramos en 11ty: cero JavaScript en el cliente por defecto, sin magia, sin estructura impuesta.

Lo que busco es algo que comparta esa misma filosofía: un generador que salga del camino. Que no inyecte nada en mi HTML sin pedírselo. Que soporte múltiples lenguajes de plantillas. Que sea mantenido por una comunidad real —o al menos por una persona comprometida sin agenda corporativa—. Y que tenga builds rápidos.

Lume: el sucesor espiritual

Buscando alternativas me he encontrado con Lume, y la impresión ha sido inmediata. Creado y mantenido por Óscar Otero, un desarrollador gallego, Lume es un generador de sitios estáticos construido sobre Deno que comparte con 11ty una cantidad notable de principios: soporte para múltiples lenguajes de plantillas, cero JavaScript en el cliente por defecto, estructura de proyecto libre, y una configuración en TypeScript que resulta familiar a cualquier usuario de Eleventy. Que sea un proyecto nacional, de un desarrollador independiente con una filosofía clara, también pesa en la balanza.

La gran diferencia respecto a un proyecto Node.js es que Deno elimina completamente la carpeta node_modules. Las dependencias se descargan y cachean automáticamente, lo que convierte el setup inicial en una experiencia notablemente más limpia. Quienes hayan sufrido alguna vez la gestión de dependencias en un proyecto Node grande entenderán lo que esto significa en términos de mantenimiento a largo plazo. Y Deno es compatible con los paquetes npm, así que la transición no implica renunciar al ecosistema existente.

En cuanto a migración, el salto desde Eleventy parece más sencillo que a cualquier otro generador. Los conceptos de layouts, includes, data files y colecciones funcionan de manera análoga. Incluso Nunjucks funciona de fábrica como lenguaje de plantillas, lo que puede facilitar mucho la migración de proyectos existentes. El proyecto lleva activo desde 2020, tiene una versión 3 estable y madura, y su repositorio en GitHub muestra commits regulares.

La comunidad de Lume es todavía pequeña comparada con la de Eleventy o Hugo. La documentación es buena pero no tan exhaustiva, y las búsquedas de soluciones a problemas específicos podrían ser menos fructíferas. Pero eso, lejos de ser un freno, es lo que hace interesante el momento: un proyecto joven donde todavía puedes formar parte de su crecimiento, contribuir con documentación, reportar problemas y sentir que tu aportación importa. Es exactamente el tipo de comunidad que muchos echamos de menos en proyectos que ya han crecido demasiado.

La decisión

No es que Eleventy haya dejado de funcionar. Es que la promesa original —un proyecto pequeño, independiente, sin compromisos comerciales— ya no está sobre la mesa. Y si una de las razones por las que uso generadores estáticos es mantener la independencia de mi stack, tiene sentido que la herramienta que lo sostiene sea también independiente.

Hay aquí una ironía pequeña que conviene confesar: paigar.eu —el sitio donde estás leyendo este texto— ya corre sobre Lume desde su primer día. Lo monté hace meses como experimento personal: un proyecto pequeño, controlado, donde podía permitirme romper cosas y aprender por el camino sin coste para nadie. Lo que iba a ser una prueba terminó siendo lo definitivo, y este post se escribe ya sobre la herramienta cuya elección defiende.

La conversación de fondo —"si funciona, migro; si no, Eleventy sigue ahí"— la dejo para Idenautas, que es el sitio donde se juega la cara con clientes y donde la migración tiene consecuencias prácticas. Allí la decisión sigue abierta, todavía sopesando esfuerzos. Pero la noticia del rebrand de Eleventy no hace más que confirmar que la apuesta valía la pena, y que tarde o temprano todo lo que hoy mantengo en 11ty va a terminar sobre Deno.

A veces las herramientas que más quieres son las que te empujan a mirar más allá de ellas.

El problema, muchas veces, no está en quien rellena el campo. Está en quien lo programó. Porque validar un DNI, un NIE o un pasaporte no es algo especialmente complicado, pero tampoco es tan trivial como aplicar una expresión regular y dar el asunto por zanjado.

La anatomía del DNI español

El Documento Nacional de Identidad español tiene una estructura muy concreta: ocho dígitos numéricos seguidos de una letra. Esa letra no es decorativa ni aleatoria —es una letra de control calculada a partir de los ocho dígitos, y ahí está la clave de la validación.

El algoritmo es sencillo: se toma el número formado por los ocho dígitos, se divide entre 23, y el resto de esa división se usa como índice para localizar la letra correspondiente en una cadena de 23 caracteres: TRWAGMYFPDXBNJZSQVHLCKE. Si la letra que aparece en el documento coincide con la que devuelve el algoritmo, el DNI es válido. Si no coincide, algo va mal —ya sea un error tipográfico o un intento de colar un número inventado.

const LETRAS = "TRWAGMYFPDXBNJZSQVHLCKE";

function validarDNI(dni) {
	const match = dni.toUpperCase().match(/^(\d{8})([A-Z])$/);
	if (!match) return false;
	const numero = parseInt(match[1], 10);
	const letra = match[2];
	return LETRAS[numero % 23] === letra;
}

Vale la pena destacar que las letras I, O, U y Ñ no aparecen en esa cadena, precisamente para evitar confusiones tipográficas con el 1, el 0, o simplemente por convención histórica. Nuestros antepasados burócratas tenían su lógica.

El NIE, primo hermano con letra por delante

El Número de Identificación de Extranjero sigue la misma lógica de validación que el DNI, pero con una diferencia estructural: empieza por una de estas tres letras —X, Y o Z— seguida de siete dígitos y la letra de control al final.

Para aplicar el mismo algoritmo, hay que sustituir esa letra inicial por su equivalente numérico: X se convierte en 0, Y en 1 y Z en 2. Con ese número reconstruido, el cálculo es idéntico al del DNI.

function validarNIE(nie) {
	const match = nie.toUpperCase().match(/^([XYZ])(\d{7})([A-Z])$/);
	if (!match) return false;
	const prefijo = { X: "0", Y: "1", Z: "2" };
	const numero = parseInt(prefijo[match[1]] + match[2], 10);
	const letra = match[3];
	return LETRAS[numero % 23] === letra;
}

Un detalle que merece atención: el NIE con prefijo Z es relativamente reciente. Si tu base de usuarios es antigua y no lo contemplas, podrías estar dejando fuera a un buen número de personas. La burocracia evoluciona, los formularios también deberían.

El pasaporte, el pariente sin algoritmo público

Aquí las cosas se complican levemente, porque no existe un algoritmo público de validación de dígito de control para los pasaportes españoles. Lo que sí podemos hacer es validar el formato: los pasaportes españoles actuales siguen una estructura de dos o tres letras seguidas de cinco o seis dígitos numéricos.

No es una validación matemáticamente infalible —alguien con imaginación podría inventar un AAA123456 perfectamente formateado pero inexistente—, pero sirve para descartar entradas claramente incorrectas y guiar al usuario hacia el formato esperado.

function validarPasaporte(pasaporte) {
	return /^[A-Z]{2,3}\d{5,6}$/i.test(pasaporte);
}

Si tu aplicación necesita verificar que un pasaporte es real y pertenece a quien dice ser, eso ya es otro asunto —y probablemente implica APIs de terceros y consideraciones legales que se escapan del alcance de un campo de formulario.

Juntarlo todo: detección automática del tipo de documento

Lo ideal, desde el punto de vista de la experiencia de usuario, es no obligar a la persona a indicar si su documento es un DNI, un NIE o un pasaporte. El formato ya lo dice. Podemos detectarlo automáticamente con una función que evalúa la estructura del valor introducido y llama a la función de validación correspondiente.

const LETRAS = "TRWAGMYFPDXBNJZSQVHLCKE";

function validarDNI(doc) {
	const m = doc.match(/^(\d{8})([A-Z])$/);
	if (!m) return { valido: false };
	const ok = LETRAS[parseInt(m[1], 10) % 23] === m[2];
	return { tipo: "DNI", valido: ok };
}

function validarNIE(doc) {
	const m = doc.match(/^([XYZ])(\d{7})([A-Z])$/);
	if (!m) return { valido: false };
	const pref = { X: "0", Y: "1", Z: "2" };
	const ok = LETRAS[parseInt(pref[m[1]] + m[2], 10) % 23] === m[3];
	return { tipo: "NIE", valido: ok };
}

function validarPasaporte(doc) {
	const ok = /^[A-Z]{2,3}\d{5,6}$/.test(doc);
	return { tipo: "Pasaporte", valido: ok };
}

function validarDocumento(raw) {
	const doc = raw
		.trim()
		.toUpperCase()
		.replace(/[\s\-\.]/g, "");

	if (/^\d{8}[A-Z]$/.test(doc)) return validarDNI(doc);
	if (/^[XYZ]\d{7}[A-Z]$/.test(doc)) return validarNIE(doc);
	if (/^[A-Z]{2,3}\d{5,6}$/.test(doc)) return validarPasaporte(doc);

	return { tipo: "desconocido", valido: false };
}

Fíjate en el replace(/[\s\-\.]/g, '') antes de evaluar: es un pequeño gesto de buena fe hacia el usuario que escribe 12.345.678-Z o 12 345 678 Z. Limpiar la entrada antes de validarla evita muchos falsos negativos innecesarios.

Integración en un formulario real

Con la función lista, integrarla en un campo de formulario es cuestión de escuchar el evento input y actuar en consecuencia. No hay que esperar a que el usuario pulse «Enviar» para decirle que algo va mal —la validación en tiempo real, con un poco de gracia y sin ponerse histérico con el primer carácter, mejora notablemente la experiencia.

const campo = document.getElementById("documento");
const aviso = document.getElementById("aviso-documento");

campo.addEventListener("input", () => {
	const resultado = validarDocumento(campo.value);

	if (!campo.value.trim()) {
		aviso.textContent = "";
		campo.removeAttribute("aria-invalid");
		return;
	}

	if (resultado.valido) {
		aviso.textContent = `${resultado.tipo} válido ✓`;
		aviso.className = "aviso ok";
		campo.setAttribute("aria-invalid", "false");
	} else {
		aviso.textContent =
			resultado.tipo === "desconocido"
				? "Formato no reconocido"
				: `La letra de control no es correcta`;
		aviso.className = "aviso error";
		campo.setAttribute("aria-invalid", "true");
	}
});

Un apunte de accesibilidad que conviene no ignorar: usar aria-invalid sobre el campo permite que los lectores de pantalla comuniquen el estado del campo a quienes los necesitan. No cuesta nada y marca la diferencia para una parte nada despreciable de los usuarios.

Una última consideración antes de confiar ciegamente en esto

La validación del lado del cliente es útil para mejorar la experiencia de usuario, pero nunca debe ser la única línea de defensa. Cualquiera puede desactivar JavaScript o manipular las peticiones antes de que lleguen al servidor. Si el número de documento tiene alguna relevancia funcional en tu aplicación —y probablemente la tiene si lo estás pidiendo—, repite siempre la validación en el servidor.

Lo que hemos visto aquí es suficiente para que tus formularios sean más amables, más inteligentes y menos fuente de fricciones innecesarias. Que no es poco.

A continuación puedes encontrar un validador funcional con todo lo que hemos descrito: detección automática del tipo de documento, validación en tiempo real y ejemplos para probar.

Crear esas imágenes a mano para cada post es tedioso. Y conectar un servicio externo para algo tan simple es sobredimensionar el problema. La solución está en el propio build: generar las imágenes durante la compilación, sin servicios externos.

La idea original la encontré en el artículo de Bernard Nijenhuis para Eleventy, y la he adaptado a Lume con las herramientas que Deno ofrece.

La estrategia

El truco es usar SVG como plantilla intermedia. SVG es código, así que puedes generarlo programáticamente. Después, una librería WASM convierte ese SVG a PNG durante el build.

El flujo completo:

1. Un generador TypeScript (og-images.page.ts) produce un archivo SVG por cada post
2. El SVG contiene el título del post, la sección y el branding del sitio
3. Después del build, un evento afterBuild en _config.ts convierte todos los SVG a PNG con resvg
4. Las meta tags og:image apuntan a las imágenes PNG generadas

Todo ocurre en el build. No hay servicios externos, no hay APIs, no hay imágenes que mantener a mano.

El generador: og-images.page.ts

En Lume, los archivos .page.ts son generadores: exportan una función que puede producir múltiples páginas. Cada yield genera un archivo. Es el equivalente a la paginación de otros SSG, pero con TypeScript puro.

El generador empieza recopilando todos los posts de ambas secciones con search.pages():

export default function* ({ search }: Lume.Data) {
	const posts = [...search.pages("bitacora"), ...search.pages("reflexiones")];

	for (const post of posts) {
		const title = post.title as string;
		const tags = (post.tags || []) as string[];
		// ...
	}
}

Para cada post hay que resolver tres cosas: partir el título en líneas, determinar la sección, y extraer el slug para el nombre de archivo.

Partir el título en líneas

SVG no sabe partir texto automáticamente. Si el título tiene 80 caracteres, se sale del canvas. La solución es dividir el texto en líneas de máximo 36 caracteres, cortando siempre por espacios:

const parts = title.split(" ");
const titleLines: string[] = parts.reduce((prev: string[], current: string) => {
	if (!prev.length) return [current];
	const lastLine = prev[prev.length - 1];
	if (lastLine.length + 1 + current.length > 36) {
		return [...prev, current];
	}
	prev[prev.length - 1] = lastLine + " " + current;
	return prev;
}, []);

El 36 depende del tamaño de fuente y del ancho del canvas. Con font-size="48" y un canvas de 1200 px, 36 caracteres encajan bien.

Posición vertical del título

La posición Y del título se ajusta según el número de líneas, para que quede centrado visualmente en la imagen:

const lineCount = titleLines.length;
let titleY: number;
if (lineCount === 1) titleY = 310;
else if (lineCount === 2) titleY = 280;
else if (lineCount === 3) titleY = 240;
else titleY = 200;

Sección y slug

La sección se determina a partir de los tags del post. El slug se extrae de la URL — es el último segmento:

const seccion = tags.includes("bitacora") ? "BITACORA" : "REFLEXIONES";

const urlParts = (post.url as string).split("/").filter(Boolean);
const slug = urlParts[urlParts.length - 1];

El SVG

Con todos los datos preparados, se construye el SVG como un template literal. Las líneas del título se generan como <tspan> con la coordenada Y incrementada en 62 px por línea. El texto se escapa con una función auxiliar escapeXml para evitar que caracteres como & o < rompan el XML:

const tspans = titleLines
	.map(
		(line: string, i: number) =>
			`    <tspan x="80" y="${titleY + i * 62}">${escapeXml(line)}</tspan>`,
	)
	.join("\n");

El diseño es intencionalmente sencillo: fondo oscuro (#111118), una barra naranja lateral (#f86624) como marca visual, el nombre de la sección en naranja, el título en claro, y el branding del sitio abajo. Todo con <rect>, <text>, <line> y <circle>.

Finalmente, el generador produce el archivo:

yield {
  url: `/og-images/${slug}.svg`,
  content: svg,
};

Por qué PNG y no JPEG o WebP

La elección del formato no es casual. Estas imágenes son texto sobre fondos planos, sin fotografías ni degradados complejos. PNG comprime ese tipo de contenido muy bien y mantiene los bordes del texto nítidos. JPEG introduciría artefactos de compresión visibles en las letras y líneas rectas — necesitarías calidad alta para disimularlos, y el archivo acabaría pesando lo mismo o más.

WebP sería ideal por tamaño, pero los crawlers de redes sociales (Facebook, LinkedIn, WhatsApp) históricamente han tenido problemas con WebP en og:image. Facebook recomienda oficialmente PNG o JPEG.

En la práctica, las imágenes generadas pesan entre 22 y 38 KB. No merece la pena buscar más optimización.

La conversión: SVG a PNG con resvg-wasm

Los SVG no sirven directamente como imágenes Open Graph — los crawlers de redes sociales esperan formatos rasterizados. Aquí es donde la migración a Lume trajo un reto interesante.

En Eleventy, la conversión era trivial: @11ty/eleventy-img usa Sharp, que es una librería nativa de Node.js con bindings precompilados. En Deno, Sharp no funciona directamente. Y la mayoría de paquetes npm de conversión SVG→PNG están o deprecados, o usan binarios nativos incompatibles con Deno, o tienen APIs inestables.

La solución fue resvg-wasm, una versión compilada a WebAssembly del renderizador SVG de Mozilla. Funciona en cualquier plataforma sin binarios nativos.

La conversión se ejecuta en un evento afterBuild de Lume, cuando los SVG ya están generados en _site/og-images/:

import { render as renderSvgToPng } from "https://deno.land/x/resvg_wasm@0.2.0/mod.ts";

site.addEventListener("afterBuild", async () => {
	const ogDir = site.dest() + "/og-images";

	try {
		const entries = [...Deno.readDirSync(ogDir)];
		const svgFiles = entries.filter((e) => e.name.endsWith(".svg"));

		if (svgFiles.length === 0) return;

		let converted = 0;
		for (const entry of svgFiles) {
			const svgPath = `${ogDir}/${entry.name}`;
			const pngPath = svgPath.replace(".svg", ".png");
			const svgContent = await Deno.readTextFile(svgPath);

			const pngBuffer = await renderSvgToPng(svgContent);
			await Deno.writeFile(pngPath, pngBuffer);
			await Deno.remove(svgPath);
			converted++;
		}

		console.log(`[og-images] ${converted} SVG convertidos a PNG`);
	} catch (err) {
		if (!(err instanceof Deno.errors.NotFound)) {
			console.error("[og-images] Error:", err);
		}
	}
});

La API es mínima — una sola función render() que recibe SVG como string y devuelve PNG como Uint8Array. Por cada SVG, genera el PNG y elimina el original.

Las meta tags

Solo queda apuntar las meta tags a las imágenes generadas. En el layout base:

{{ if tags && (tags.includes("bitacora") || tags.includes("reflexiones")) }}
<meta
	property="og:image"
	content="{{ metadata.url }}/og-images/{{ page.src.slug }}.png" />
{{ else }}
<meta property="og:image" content="{{ metadata.url }}/og-images/default.png" />
{{ /if }}
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta name="twitter:card" content="summary_large_image" />

Los posts obtienen su imagen específica. El resto de páginas usan una imagen genérica con el nombre y la descripción del sitio. El valor summary_large_image en twitter:card hace que la imagen se muestre en grande al compartir en X.

Sobre las fuentes

Un detalle importante: el renderizador SVG usa las fuentes del sistema donde se ejecuta el build. Si usas una tipografía personalizada que no está instalada en la máquina, el resultado será diferente. En mi caso uso Arial como fuente para las imágenes OG, que está disponible en prácticamente cualquier sistema.

El archivo completo

Para referencia, este es el og-images.page.ts completo tal como funciona en producción:

export default function* ({ search }: Lume.Data) {
	const posts = [...search.pages("bitacora"), ...search.pages("reflexiones")];

	for (const post of posts) {
		const title = post.title as string;
		const tags = (post.tags || []) as string[];

		const parts = title.split(" ");
		const titleLines: string[] = parts.reduce(
			(prev: string[], current: string) => {
				if (!prev.length) return [current];
				const lastLine = prev[prev.length - 1];
				if (lastLine.length + 1 + current.length > 36) {
					return [...prev, current];
				}
				prev[prev.length - 1] = lastLine + " " + current;
				return prev;
			},
			[],
		);

		const lineCount = titleLines.length;
		let titleY: number;
		if (lineCount === 1) titleY = 310;
		else if (lineCount === 2) titleY = 280;
		else if (lineCount === 3) titleY = 240;
		else titleY = 200;

		const seccion = tags.includes("bitacora") ? "BITACORA" : "REFLEXIONES";

		const urlParts = (post.url as string).split("/").filter(Boolean);
		const slug = urlParts[urlParts.length - 1];

		const tspans = titleLines
			.map(
				(line: string, i: number) =>
					`    <tspan x="80" y="${titleY + i * 62}">${escapeXml(line)}</tspan>`,
			)
			.join("\n");

		const svg = `<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="1200" height="630" viewBox="0 0 1200 630" xmlns="http://www.w3.org/2000/svg">

  <!-- Fondo -->
  <rect width="1200" height="630" fill="#111118"/>

  <!-- Barra naranja lateral -->
  <rect x="0" y="0" width="8" height="630" fill="#f86624"/>

  <!-- Seccion -->
  <text x="80" y="${titleY - 60}" font-family="Arial, Helvetica, sans-serif" font-size="22" fill="#f86624" letter-spacing="3">${seccion}</text>

  <!-- Titulo -->
  <text font-family="Arial, Helvetica, sans-serif" font-size="48" font-weight="bold" fill="#dcdcd4">
${tspans}
  </text>

  <!-- Linea separadora -->
  <line x1="80" y1="530" x2="1120" y2="530" stroke="#2a2a3a" stroke-width="1"/>

  <!-- Branding -->
  <text x="80" y="575" font-family="Arial, Helvetica, sans-serif" font-size="24" fill="#8e8e86">paigar.es</text>

  <!-- Punto naranja -->
  <circle cx="1120" cy="568" r="6" fill="#f86624"/>

</svg>`;

		yield {
			url: `/og-images/${slug}.svg`,
			content: svg,
		};
	}
}

function escapeXml(str: string): string {
	return str
		.replace(/&/g, "&amp;")
		.replace(/</g, "&lt;")
		.replace(/>/g, "&gt;")
		.replace(/"/g, "&quot;")
		.replace(/'/g, "&apos;");
}

La alternativa oficial: el plugin og_images

Lume tiene un plugin oficial de imágenes Open Graph que resuelve el mismo problema. Usa Satori (de Vercel) para convertir componentes JSX en SVG, y Sharp para rasterizar a PNG. Los layouts se definen como funciones JSX con estilos inline, y se asignan desde el frontmatter con openGraphLayout.

Es una opción válida si prefieres un enfoque más integrado con el ecosistema de Lume. En mi caso elegí la implementación manual por varias razones:

• Control total del SVG — puedo usar cualquier elemento SVG (<line>, <circle>, <tspan>) sin las limitaciones de Satori, que solo soporta un subconjunto de CSS basado en flexbox.
• Sin Sharp — Sharp es una librería nativa de Node.js que no funciona directamente en Deno. Con resvg-wasm no hay binarios nativos ni dependencias de plataforma.
• Menos dependencias — el generador es un único archivo TypeScript de 89 líneas, sin configuración JSX ni paquetes adicionales.

El plugin oficial es más cómodo si no necesitas un diseño muy específico o si ya usas JSX en tu proyecto. Pero para un sitio que busca minimizar dependencias, la solución manual encaja mejor.

El resultado

Con esta solución, cada vez que hago build se generan automáticamente las imágenes de vista previa para todos los posts. Sin intervención manual, sin servicios externos, sin imágenes que versionar en el repositorio. Solo código que genera código que genera imágenes.

La técnica original es para Eleventy con Sharp. Mi adaptación a Lume usa generadores .page.ts para la creación de SVGs y resvg-wasm para la conversión a PNG, eliminando la dependencia de Node.js.

Vamos a hablar de todo esto.

El patrón es siempre el mismo

El formato está tan pulido que parece un producto en sí mismo. Comienza con el gancho: los ingresos, el número, la prueba de que funciona. Luego viene la historia de origen —normalmente alguien que no tiene formación técnica, que lo intentó con otras cosas, que encontró esta herramienta casi por casualidad—. Después, el proceso: capturas de pantalla de Claude o ChatGPT escribiendo código, un Bubble o un Cursor haciendo magia, una interfaz que parece profesional surgida de la nada. Y al final, los ingresos otra vez, esta vez desglosados por plataforma, con un gráfico que sube hacia la derecha como si fuera la ley natural del universo.

El vídeo dura entre ocho y quince minutos, tiene música de fondo que transmite urgencia sin ser molesta, y termina con una llamada a la acción: suscríbete, apúntate a mi newsletter, compra mi curso de 97 dólares donde te lo explico todo.

Ese último detalle es importante. Volvemos a él.

¿Es real? Sí. Y también no

La respuesta honesta es que el fenómeno es real pero las cifras son una selección muy conveniente de la realidad. Sí, existen personas que han construido herramientas funcionales con poca o ninguna experiencia en programación usando los modelos actuales de IA. Eso es verdad y es genuinamente notable. La barrera técnica para crear algo que funcione se ha reducido de forma dramática en los últimos dos años. Alguien con paciencia, criterio para entender qué quiere construir y disposición a iterar puede llegar bastante lejos.

Lo que ya no es tan claro es lo de los miles de dólares mensuales. No porque sea imposible —hay casos reales documentados— sino porque lo que ves en YouTube es el 0,1% que funcionó, contado por alguien que tiene incentivos muy concretos para contarlo de esa manera. El 99,9% de las apps construidas así no llegan a diez usuarios de pago, se abandonan en dos meses, o generan ingresos tan modestos que no justifican el tiempo invertido. Pero esos vídeos no se hacen porque no tienen thumbnail atractivo.

Hay también una cuestión de sincronización. Muchos de los casos que funcionaron lo hicieron en ventanas de tiempo muy específicas, cuando una categoría de herramienta no existía y había demanda sin cubrir. Llegar tarde a ese nicho, cuando ya hay cinco competidores haciendo lo mismo con más recursos, es otra historia.

La paradoja que nadie responde

Aquí está la pregunta que me parece más interesante y que curiosamente casi nadie hace en los comentarios: si realmente estás ganando doce mil dólares al mes con una app, ¿por qué lo cuentas?

No es una pregunta retórica ni un ataque. Es genuina. Si descubres una veta de oro, el comportamiento racional no es colgar un cartel en YouTube para que vengan otros a picar en el mismo sitio. Los negocios que funcionan de verdad tienden a no publicitarse a sí mismos como recetas replicables, precisamente porque la replicabilidad los destruye. Si mil personas ven tu vídeo y el 5% lo intenta, acabas de crear cincuenta competidores directos en tu nicho.

La respuesta, claro, es que el vídeo no es un gesto de generosidad ni un diario íntimo de éxito. Es parte del negocio. Y el negocio no es la app.

El negocio de verdad es el canal

Lo que están vendiendo no es la app. Están vendiendo la narrativa de que la app es posible. Y eso lo monetizan de cinco formas distintas que a menudo se solapan: los ingresos de YouTube por publicidad, los programas de afiliados de las herramientas que mencionan (Cursor, Bubble, Supabase, y cualquier SaaS que pague comisiones), los cursos y mentorías, la newsletter con upselling, y en algunos casos el propio prestigio que luego se convierte en consultoría o inversión.

Un canal de YouTube con cien mil suscriptores en el nicho de indie hacking o no-code puede generar entre dos mil y diez mil dólares al mes solo en publicidad, y otro tanto en afiliados si los links están bien colocados. Añade un curso de noventa y siete euros que se vende a trescientas personas al mes y tienes un negocio muy sólido que no tiene nada que ver con ninguna app.

¿Y la app? La app es el MacGuffin. Es lo que hace que el vídeo sea creíble, lo que da autoridad al creador, lo que convierte el canal en algo más que opiniones. Puede que exista, puede que incluso gane algo de dinero. Pero no es la fuente principal de ingresos. Es el argumento de venta del verdadero producto, que eres tú aprendiendo a hacer lo que él ya hizo.

¿Merece la pena montar esto si ya tienes ingresos?

Hay una última capa en todo esto que me parece fascinante desde el punto de vista del esfuerzo versus retorno. Imagina que tienes un negocio digital que te genera varios miles de euros al mes de forma más o menos estable, sin necesidad de crear contenido constantemente, sin algoritmos de por medio, sin tener que estar delante de una cámara con cara de entusiasmo cada semana.

¿Tiene sentido en ese contexto montar un canal de YouTube que te exige producir vídeos con regularidad, optimizar thumbnails, gestionar comentarios, depender del humor del algoritmo de Google y construir una audiencia desde cero? La respuesta no es automáticamente no, pero tampoco es automáticamente sí. Depende de si te gusta crear ese tipo de contenido por sí mismo, no solo como medio para un fin.

Porque eso es lo que muchos de estos creadores no dicen: hacer un canal de YouTube que funcione de verdad es un trabajo a tiempo completo, y hacerlo bien durante meses sin ingresos iniciales requiere una tolerancia a la incertidumbre bastante alta. El que ya tiene sus ingresos cubiertos por otra vía puede hacerlo desde una posición más cómoda, claro. Pero entonces tampoco tiene la urgencia narrativa del "lo construí desde cero sin nada" que hace que los vídeos enganchen.

La trampa es sutil: admiras a alguien que parece que ganó dos veces al mismo tiempo, con la app y con el canal, cuando en realidad probablemente perdió bastante tiempo y dinero con la app antes de que el canal se convirtiera en lo que realmente paga las facturas. El orden importa, y el orden raramente aparece en el thumbnail.

Pero llevo un tiempo dándole vueltas al tema, y hay un par de cosas que conviene poner en orden antes de seguir tragando con la narrativa oficial de que pagar con tarjeta es siempre, automáticamente, un avance. Porque hay un trozo de la película que casi nadie cuenta. Y cuando alguien me lo contó en su momento con un ejemplo muy sencillo, ya no he conseguido dejar de verlo.

El ejemplo del billete de cincuenta euros

Imagina un billete de cincuenta euros. Sale de tu cartera y entra en la caja de una tienda de barrio cuando pagas la compra. El tendero, al cabo de unos días, usa ese mismo billete para pagar a su distribuidor. El distribuidor lo lleva en la cartera y se lo deja al empleado de la gasolinera al llenar el depósito. El empleado de la gasolinera, esa misma noche, paga con él la cena en un restaurante. El cocinero del restaurante lo coge para pagar al pescadero al día siguiente. Y así sucesivamente, durante veinte transacciones, treinta, las que tú quieras imaginar.

Al final del recorrido, el billete vale exactamente lo que valía al principio: cincuenta euros. Sigue ahí, intacto, listo para participar en la siguiente operación. Ha facilitado decenas de intercambios económicos sin perder un céntimo por el camino. Su valor es estable, completo, íntegro.

Ahora imagina ese mismo recorrido pero pagando con tarjeta. Tú pagas tus cincuenta euros en la tienda de barrio y, entre el banco emisor, la red de pago y otros intermediarios, se quedan cinco céntimos. Una nimiedad. Cuando el tendero paga al distribuidor, otros cinco céntimos. Cuando el distribuidor paga la gasolina, otros cinco. Cuando el empleado paga la cena en el restaurante, otros cinco. Cuando el cocinero paga al pescadero, otros cinco. Y así sucesivamente. Cada operación parece insignificante por separado, una mordida tan pequeña que ni te molestas en mirarla.

Pero echa la cuenta. Después de veinte transacciones, esas mordidas insignificantes suman un euro entero. En cien transacciones, cinco euros. Y aquí está el detalle que cambia la perspectiva: veinte o cien transacciones no son nada. Un único billete de cincuenta euros, cuando estaba en circulación de mano en mano, podía participar en cientos o miles de operaciones a lo largo de su vida útil sin perder un solo céntimo. En su versión digital, esos mismos cincuenta euros, al cabo de doscientas operaciones, se han convertido en cuarenta. Diez euros han desaparecido por el camino. No los ha gastado nadie en nada. No han comprado nada. Simplemente han ido cayendo, céntimo a céntimo, en las cuentas de quienes hacen de peaje en cada transacción.

Un peaje invisible que no existía con el efectivo

Esto es lo que más me sorprende cuando lo pienso bien. Que estamos hablando de un coste que sencillamente no existía cuando usábamos efectivo. El billete de cincuenta euros pasaba de mano en mano sin que nadie cobrara comisión por intermediar. El sistema de pagos era, literalmente, gratis para todos los participantes. La fricción era cero. Y por mucho que las comisiones individuales por operación parezcan pequeñas —céntimos, fracciones de céntimo, porcentajes ridículos— el efecto acumulado es enorme cuando lo multiplicas por miles de millones de transacciones diarias en todo el mundo.

Sí, es verdad que ese dinero no se lo queda solo el banco. Se reparte entre el banco emisor, la red de pago internacional, el banco adquirente, el procesador, el fabricante del datáfono y unos cuantos intermediarios más con nombres de tres letras que casi nadie conoce. Pero a efectos prácticos, eso me da exactamente igual. Lo relevante es lo otro. Lo relevante es que los consumidores y los pequeños comerciantes han perdido colectivamente un dinero que con el efectivo no perdían, y que ese dinero ha aterrizado en los balances de un sector financiero que jamás había tenido acceso tan directo y tan automático a un porcentaje de cada compra que se hace en el mundo. Eso es un cambio histórico de proporciones inmensas, y se ha colado en nuestra vida cotidiana sin debate público alguno, simplemente porque el datáfono pita más rápido que la calderilla.

Y encima te cobran por usar tu propio dinero

Como si esto no fuera suficiente, el sistema tiene capas adicionales. Muchos bancos cobran a sus clientes una cuota anual por el simple hecho de tener una tarjeta. Pagas a tu banco para que te deje pagar. Es un giro lingüístico tan absurdo que cuando lo dices en voz alta cuesta creérselo, pero ahí está, en los extractos mensuales, año tras año. Hay tarjetas gratuitas si cumples ciertos requisitos —domiciliar la nómina, alcanzar un volumen de gasto, contratar otros productos—, pero eso no es gratis tampoco. Es solo otra forma de pago, esta vez en forma de fidelidad y datos.

El comercio, por su lado, paga su propia colección de tributos al sistema. Le alquilan el datáfono al banco a un precio mensual fijo. Le cobran una comisión por cada operación, normalmente como porcentaje del importe. A veces le cobran también por las operaciones canceladas, por las devoluciones, por la conexión a la red. Cuando entras en una tienda pequeña y ves el cartel que dice importe mínimo para pagar con tarjeta: diez euros, no es porque al tendero le caigas mal. Es porque para una venta de dos euros, la comisión que le cobra el banco se come directamente todo el margen. No es un capricho del tendero. Es supervivencia.

Y por supuesto, todos esos costes que paga el comercio no salen del aire. Salen del precio que pagamos los consumidores. Cuando compras una barra de pan, una parte minúscula de su precio está pagando la comisión que el datáfono cobrará si pagas con tarjeta, aunque tú pagues en efectivo. El sobrecoste se ha incorporado al precio final de las cosas, igual que se incorporan otros costes operativos. La diferencia es que este es un coste añadido por una infraestructura que antes no existía y de la que no podemos prescindir, porque cada vez hay más sitios donde directamente no aceptan otra cosa.

El servicio que recibimos a cambio de toda esta sangría

Aquí es donde la cosa empieza a ser ya directamente irritante. Porque uno podría aceptar todos estos costes si recibiera a cambio un servicio espectacular. Pues no. El servicio que ofrece la banca al cliente medio es lamentable en una proporción difícil de exagerar. Las oficinas bancarias se han ido cerrando una tras otra. Las que quedan abren con horarios laborales que coinciden exactamente con los horarios laborales del cliente, lo cual es magia logística pura. Las operaciones en ventanilla están racionadas como si fuesen un bien escaso: pagos de recibos en horario restringido, retirada de efectivo solo hasta una hora concreta de la mañana, gestiones presenciales atendidas con cita previa concertada con varios días de antelación.

Esto no lo digo desde la queja del que pierde el tiempo en colas. Lo digo desde la constatación objetiva de que el sector financiero ha conseguido, en pocos años, cobrar más por hacer menos. Más comisiones por operación, menos atención al cliente. Más cuotas por tarjeta, menos oficinas. Más beneficios récord trimestrales, menos servicio. Y todo bajo la narrativa de la digitalización y la modernidad, como si renunciar a hablar con un humano cuando tienes un problema con tu propio dinero fuera un avance civilizatorio. No lo es. Es el resultado de un cambio en el equilibrio de fuerzas entre el sector y sus clientes que se ha producido sin que apenas nadie protestase.

Y queda otro detalle que me parece importante mencionar, aunque sea brevemente: la privacidad. El efectivo es anónimo. Cuando pagas un café con un billete, nadie sabe que has pagado un café. Cuando pagas con tarjeta, hay un registro permanente de qué compraste, dónde, a qué hora, junto a qué otras compras y por qué importe. Ese registro lo guardan tu banco, la red de pago, el comercio, sus respectivos proveedores tecnológicos y, dependiendo de la jurisdicción, varias administraciones más. Es un nivel de trazabilidad de la vida cotidiana que hace cuarenta años habría parecido distopía y que hoy hemos aceptado a cambio de pagar el supermercado más rápido. Que cada cual decida si el intercambio le compensa, pero al menos conviene que lo decida sabiéndolo.

Lo que estoy haciendo, sin pretender heroísmos

No voy a venir aquí a anunciar que he desterrado la tarjeta de mi vida. No es verdad ni lo va a ser. La pereza, la prisa, la comodidad y la cantidad de sitios donde ya directamente no aceptan otra cosa pesan demasiado para fingir lo contrario. En el supermercado, después de quince minutos llenando el carro, sigo prefiriendo pasar el plástico mientras embolso que ponerme a contar monedas. En los viajes, especialmente fuera de la zona euro, el cambio de divisa en efectivo tiene sus propias trampas que muchas veces son peores que las de la tarjeta. Ser realista en estos temas también es importante, porque el moralismo del consumo ético sin matices acaba siendo siempre un postureo que no soluciona nada.

Lo que sí estoy haciendo desde hace un tiempo es un esfuerzo consciente por reducir el número de operaciones con tarjeta cuando puedo hacerlo sin grandes complicaciones. Llevar algo de efectivo encima cuando salgo. Pagar en metálico en la cafetería, en la panadería, en el bar del barrio, en los pequeños comercios donde sé que cada comisión se le come el margen al dueño. Sacar una cantidad razonable de dinero del cajero al principio de la semana y administrarla. Pequeños gestos que individualmente no cambian nada, pero que al menos me permiten saber que no estoy contribuyendo automáticamente, en cada movimiento, al peaje invisible que hemos aceptado sin discutirlo.

Y mientras tanto, recordar de vez en cuando el ejemplo del billete de cincuenta euros. Que circulaba cien veces y seguía valiendo cincuenta. Y que ahora, en su versión digital, circula cien veces y vale cuarenta y cinco. Cinco euros que se han evaporado por el camino sin haber comprado nada. Y multiplica eso por todos los billetes virtuales que circulan cada día en una economía moderna. La cifra que sale es astronómica. Y es una cifra que alguien se está quedando. No tú. No el tendero. No el camarero. Alguien que hace de peaje y que no estaba ahí antes. Y que cuando uno se para a mirar quién es y cuánto está cobrando por estar ahí, la respuesta no resulta especialmente tranquilizadora.

Ahora lo otro. Porque hay un pero enorme, y no me lo puedo guardar.

Algunas canciones que en disco sonaban muy bien hicieron un poco de aguas sobre el escenario. No voy a hacer leña del árbol caído, que para eso ya hay críticos con mucho tiempo libre. Pero sí voy a hablar —necesito hablar— de lo que me tiene todavía dándole vueltas días después de la final. De lo que, siendo honesto, me parece una injusticia bastante gorda.

Rosalinda Galán y tres minutos que me dejaron sin palabras

No sabía muy bien quién era Rosalinda Galán antes del festival. Lo reconozco. Sevillana, cantante de copla desde pequeña, se define a sí misma como "folclórica estrafalaria" —ya solo por eso merece todo mi respeto—, y llegó al Benidorm Fest con una canción llamada "Mataora" que, la primera vez que la escuché en disco, pensé: qué cosa más rara y qué cosa más buena.

La canción está construida sobre el personaje de Carmen, la de Mérimée, sí, la de la ópera de Bizet, esa Carmen que llevan siglos contando los demás. Pero aquí Carmen habla ella. Se presenta, reivindica su libertad, corta sus propias trenzas cuando intentan retenerla. "Me agarran fuerte del pelo / y yo me corto las trenzas." Cuatro palabras por verso y ahí está todo dicho. No es una canción fácil ni pegadiza ni de esas que te tarareas en la ducha. Es una canción que te agarra de algún sitio y no te suelta.

Pero lo de la actuación en directo ya fue otra cosa.

Un plano secuencia que no me esperaba ver en televisión

No soy ningún experto en realización televisiva ni en técnica audiovisual. Lo que sé es lo que me gusta y lo que no. Y lo que vi en esa actuación me pareció de una categoría diferente a todo lo demás de la noche, y probablemente de todo lo que he visto en el festival desde que existe.

La filmaron en un único plano sin cortes —lo que se llama un plano secuencia, que ya es complicado de por sí— pero además jugando con pasar del blanco y negro al color según la música respiraba de una manera u otra. Los momentos más copleros, más de raíz, en blanco y negro. Y cuando la canción se abría y se electrificaba, el color aparecía con rojos y sombras que se proyectaban sobre Rosalinda y el fondo como si el escenario estuviera vivo. No sé cómo lo hicieron. Bueno, sí sé algo: en un momento dado la cámara subió por encima de ella en un plano desde arriba que me pareció imposible de conseguir en un directo, y resulta que lo lograron colgando literalmente a un operador del techo del pabellón. Del techo. En directo. En una final de televisión.

Cuando vi ese plano, paré. Me quedé mirando la pantalla sin hacer nada. Eso no me pasa muy a menudo.

Lo que pasó después todavía no lo entiendo

Ganó "T Amaré" de Tony Grox y LUCYCALYS. Que es un temazo, que tiene un estribillo enorme, que la gente lo coreaba y se lo pasaba en grande, y que tiene todo el derecho del mundo a existir y a gustar. No tengo nada en contra.

Pero es que Rosalinda Galán estaba ahí. Con esa canción. Con esa actuación. Con ese plano secuencia y esas sombras y esa voz y esa Carmen que por fin se contaba a sí misma. Y no ganó.

Los premios secundarios —el de Spotify, el de Univisión— me parecieron razonables para lo que eran. Pero la Sirenita de Oro, el premio gordo, ese era el de Rosalinda. O al menos eso pensé yo, y al parecer lo pensaba mucha gente, porque era una de las favoritas y terminó sin nada.

Entiendo que los festivales de televisión no los ganan siempre las propuestas más arriesgadas. Lo entiendo perfectamente. Llevo suficientes años viendo este tipo de cosas como para no sorprenderme. Pero entenderlo no me impide pensar que fue una injusticia. Una de esas injusticias menores, de las que no cambian el mundo, pero que duelen un poco de todas formas.

Rosalinda Galán subió a ese escenario con una canción sobre una mujer libre, con un homenaje muy discreto a su padre recién fallecido, y con una puesta en escena que demostraba que cuando alguien cree de verdad en lo que está haciendo, eso se ve. Vaya si se ve.

Que no haya ganado es cosa del festival. Pero que la actuación exista y que podamos volver a ella cuando queramos, eso ya es cosa de Rosalinda. Y de Carmen. Y de todas las que se cortan las trenzas.

Si no la has visto: busca "Mataora – Rosalinda Galán – Benidorm Fest 2026 Final" en YouTube. Merece los tres minutos.