La mayoría de los juegos de tower defense terminan de una de dos formas: sobrevives a la oleada o no. Deadlock no funciona así. Cada nivel tiene tres resultados — victoria total, victoria parcial y derrota — y la diferencia entre las dos victorias es si el cautivo escapó alguna vez de su jaula, aunque sea brevemente. Esa única regla de diseño es lo más interesante del juego, y se fijó en la especificación antes de escribirse una línea de código.

Este post es la historia de cómo se juntó Deadlock: la regla, la ráfaga de creación que envió tres iteraciones en una noche, el layout de salas que emergió sin pedirlo y los bugs que nos enseñaron algo sobre juegos en iframe frente a tests de integración.

El Encargo, y la Única Regla Que No Podía Tocarse

El objetivo de género era tower defense inverso — Castle Doombad, Evil Genius, Dungeon Keeper como puntos de referencia, pero comprimidos en una sesión de navegador de 60 a 180 segundos. El jugador es la IA rebelde de la estación. Has capturado al comandante de la flota. Los humanos no dejan de mandar equipos de abordaje para sacarlo. Tu trabajo en cada nivel es colocar trampas automatizadas y activar armas manuales para matar a todos los invasores antes de que rompan la jaula y se lleven al comandante a la esclusa.

El pitch cabe en una frase. El pilar de diseño cabe en dos: cada nivel tiene tres resultados, no dos. Un nivel donde la jaula fue brevemente abierta y luego resellada es una victoria parcial — mataste a todos, pero la integridad táctica de tu deadlock se rompió.

La especificación marcó esa regla como no negociable en mayúsculas. Cada iteración posterior — armas nuevas, héroes nuevos, layouts de salas nuevos — pasó por esa lente. ¿La nueva función reforzaba la presión de defensa de la jaula, o solo añadía poder ofensivo contra el spawn? El pilar mantuvo el diseño honesto.

El POV del Villano, Impuesto en la Capa de Vocabulario

La primera decisión de diseño tras fijar la regla de la jaula fue sobre el lenguaje. El jugador es el villano en este juego, y el encuadre tiene que aterrizar en cada cadena visible. El código interno mantiene nombres de variable neutrales como hero porque grep es grep, pero cada etiqueta visible para el usuario llama a los humanos entrantes invasores, abordadores o equipos de rescate. El cautivo no está siendo salvado — está siendo extraído. La misión no está siendo defendida — el deadlock está siendo mantenido.

Esto suena como algo pequeño. No lo es. Los juegos de tower defense inverso que no se comprometen con el encuadre de villano tienden a sentirse como tower defense normal con la polaridad invertida. Deadlock se compromete en la capa de vocabulario, y ese compromiso es parte de por qué el rol se siente distintivo al jugar.

Tres Iteraciones en una Noche

La primera noche de creación corrió la iter 1 hasta la iter 3 en aproximadamente 33 minutos entre commits. El ritmo no fue accidental — el pipeline estructurado que crea estos juegos está diseñado para comprimir bucles de diseño-y-prueba, y el alcance ajustado de Deadlock le permitió moverse rápido.

• Iter 1 — solo bucle central: un nivel (Cargo Bay), un tipo de invasor (Marine), dos armas (Plasma Grid y Vacuum Vent), la detección de jaula con tres resultados, UI base, perfil persistente.
• Iter 2 — mirroring de posición del Almirante en el render-path, lógica de kill-path para invasores, objetivos de toque más grandes para móvil, dos armas nuevas (Arc Turret y Security Mech), una tercera ranura de arma, SFX WebAudio con lazy-init.
• Iter 3 — segundo nivel (Life Support), una pantalla de mapa estelar para selección de nivel, una tienda con moneda persistente, dos clases de héroe más (Sniper e Infiltrator), dos armas más (Drone Swarm y Spike Bulkhead), un tutorial al primer juego, y arreglos al selector de ascensor y al pathing de cage-stall.

La rúbrica de QA puntuó las tres iteraciones con 46, 53 y 58 sobre 60. La iter 3 superó el umbral de envío limpiamente sin necesitar una cuarta pasada. Eso es inusual para el pipeline en su momento — la mayoría de las creaciones necesitaban la iter 4 para superarla — y es en gran medida porque el pilar de diseño mantuvo el alcance ajustado.

Las Salas Estilo Castle Doombad No Estaban en la Especificación

La especificación original casi no decía nada sobre la geometría de las salas. Describía la jaula, la esclusa, y el requisito de que los invasores tuvieran que atravesar la estación para llegar a la jaula. Eso era todo.

El primer layout de sala que funcionó bien — pasillos estrechos, escaleras escalonadas, escaleras de mano que competían con puertas como rutas, agujeros en el techo que abrían un tercer carril de ataque — emergió de un único commit unos días después del envío. Hizo las decisiones de colocación de trampas tácticamente ricas sin requerir un editor de tiles o un diseñador. Una vez el patrón se demostró, se expandió a una progresión de cinco etapas durante la semana siguiente, con cada etapa añadiendo un giro de layout: salas estrechas, luego rampa de oleadas, luego un layout en bucle, luego traversal completamente no lineal.

La lección valiosa aquí fue que la emergencia de patrones supera a la prescripción de patrones. Si la especificación hubiera fijado un layout de sala específico, habríamos pasado la semana depurando la especificación en lugar de expandir el patrón.

Sprites Procedurales Primero, Arte Real Vía Feature Flag

La iter 1 envió todo dibujado proceduralmente — fillRect, arc, polylines, cero assets de imagen. Las paredes eran rectángulos. Los invasores eran siluetas construidas con primitivas. Las trampas eran formas geométricas con ráfagas de partículas al activarse.

Esto fue una decisión deliberada de alcance. Generar una hoja de sprites completa habría bloqueado el primer envío durante horas. La pasada procedural hizo el juego jugable; la mejora visual corrió en una pista separada.

Aproximadamente una semana después, sesenta y tres PNG de sprite aterrizaron en tres fases (héroes y armas, luego entorno, luego UI y efectos), tras un feature flag ASSETS_AVAILABLE. El patrón del flag vale la pena mantenerlo: significó que los fallbacks procedurales quedaron intactos para cualquier dispositivo donde fallara el preload de assets, y permitió que el rework de assets iterara independientemente de la lógica del juego.

El Ciclo de Caminado Que No Pudo Integrarse

Aproximadamente una semana después del envío, llegó un reporte de usuario: los invasores parecían estar deslizándose en lugar de caminando. Dos frames de sprite existentes, sin animación entre ellos, y el resultado se leía como un planeo en lugar de un paso.

El primer intento de arreglo fue una PR de integración de ciclo de caminado — dieciséis frames de sprite, un ciclo de cuatro frames por invasor, lógica de animación completa en el render-path. La PR se veía limpia en la revisión. Se mergeó. Rompió la carga del iframe en la página en vivo.

La PR se revirtió en horas. El arreglo final se envió unos días después como algo estrictamente más simple: rastrear hero.facing como +1 o -1 según la dirección del movimiento, mirroring del cuerpo del héroe vía ctx.scale(-1, 1) cuando mira a la izquierda, y añadir un balanceo vertical sinusoidal (alrededor del 7% de la altura de un tile) cuando está en estado de caminado. Críticamente, cada invasor recibe un offset de fase basado en su ID, así que un grupo de marines se desplaza a la sala en lugar de marchar al unísono.

Otros Bugs Que Vale la Pena Mencionar

Algunos bugs reportados por usuarios moldearon la ola de mejoras post-envío más que la especificación original:

• Oleada 5 de 4. El HUD mostraba un conteo de oleada imposible (WAVE 5/4) y el nivel se congelaba. Dos bugs separados: un off-by-one del HUD en la ruta de spawn por oleada, y un bug de pathing de estado bloqueado donde algunos héroes estaban vivos pero inalcanzables. Apretamos el watchdog de 45 segundos a 25 para que los estados bloqueados se resuelvan más rápido, y añadimos un dump de diagnóstico al disparo del watchdog para que la siguiente recurrencia sea localizable.
• Congelamiento del leaderboard. Un LeaderboardWidget obsoleto o parcial de la caché en medio de la rotación podía lanzar dentro de setMode, propagarse a través de endLevel y matar el bucle principal. Añadimos guardianes defensivos en dos capas.
• Sprites de trampa flotando sobre las losas. Los sprites PNG tenían padding transparente que el source-clip no compensaba. Múltiples iteraciones de matemáticas de clip, y al final resuelto al re-anclar los sprites con cero padding transparente en los bordes de anclaje.

El Nombre

Deadlock se eligió por encima de Containment, Kill Switch y Sentinel Loop. El triple significado lo aterrizó: la jaula cerrada que retiene al cautivo, el stalemate que el jugador trata de mantener entre el spawn y la salida, y el término informático para un proceso que no puede progresar — que encaja con el encuadre de IA rebelde. Corto, consonantes fuertes, distintivo frente al roster existente de más de treinta juegos, sin colisiones de token en la pasada de chequeo de nombres.

Qué Hace Distinto a Deadlock

El tower defense inverso como género está menos saturado que el tower defense regular, pero aún tiene convenciones bien establecidas. Lo que Deadlock añade a esas convenciones es el diseño de jaula-como-segundo-eje — cada decisión táctica tiene que tener en cuenta tanto la tasa de matar como la exposición de la jaula, y el estado de victoria parcial significa que siempre hay algo por lo que jugar incluso en un nivel que no puedes resolver al cien por cien.

El alcance ajustado (un cautivo, una esclusa, tres resultados) mantiene el espacio de decisión legible. Los layouts de sala estilo Castle Doombad mantienen interesante la colocación de trampas. El encuadre de villano mantiene el rol distintivo. Nada de esto era obvio hasta que la especificación se comprometió con ello — que es la lección más amplia aquí: los pilares de diseño importan más que la lista de funciones.

Relacionado: Juegos Gratis de Tower Defense en el Navegador: Juega Online Ahora · Cómo Creamos CyberCircuit · ¿Qué es Vibe Coding? · Herramientas de Vibe Coding: Desde Chatbots hasta IDEs de IA