Los juegos nativos del navegador se están volviendo serios: lo que revelan los proyectos de combate de código abierto

Empecé esta investigación esperando encontrar apenas unos cuantos experimentos interesantes de combate en el navegador. En cambio, encontré un ecosistema mucho más amplio: auténticos prototipos de acción en tercera persona con fijación de objetivo, árboles de combos ramificados, paradas perfectas, invulnerabilidad durante la evasión, sistemas de postura, ataques aéreos, señales previas de ataques de jefes, motion warping, hit-stop, choques físicos entre armas, compatibilidad con gamepad, controles táctiles y simulación determinista.

Ese es el resultado importante. Ya no se trata simplemente de pequeños juegos que, por casualidad, se renderizan dentro de una página web. Algunos están resolviendo los mismos problemas de ingeniería que los juegos de acción convencionales, pero se distribuyen mediante una URL y se pueden jugar de inmediato.

Para mí, como desarrollador web, esa es la parte fascinante. El antiguo modelo mental de los juegos estaba dominado por instaladores, grandes descargas, actualizadores, launchers y una espera entre descubrir un juego y poder probarlo realmente. El navegador comprime ese recorrido de forma drástica: abrir un enlace, cargar los recursos y empezar a jugar.

Esta investigación se centró en proyectos con una versión jugable en el navegador y código fuente público. Excluí intencionalmente las exportaciones Unity WebGL porque quería estudiar juegos construidos alrededor de tecnologías web, no juegos simplemente exportados a la web.

Los proyectos más sólidos que encontré

Los hallazgos más útiles no destacaban todos por la misma razón. Algunos tenían los sistemas de combos más profundos. Otros ofrecían una mejor arquitectura en tercera persona, una simulación de combate más limpia o impactos físicos más convincentes.

Por qué me sorprendieron los resultados

Lo sorprendente no fue simplemente que los gráficos se vieran bien. Renderizar una escena pulida es solo una parte del desarrollo de juegos. Los proyectos que destacaron implementaban sistemas difíciles de fingir de forma convincente: buffering de entrada, transiciones de estado de combate, selección de objetivos, movimiento durante los ataques, temporización de animaciones, detección de impactos, reacciones de enemigos, ventanas defensivas, comportamiento de la cámara y feedback de impacto.

Esto permite establecer una distinción útil:

• la temporización de la animación no es la temporización del combate;
• la frecuencia de renderizado no es la frecuencia de simulación;
• una colisión no es automáticamente un impacto válido;
• la animación no tiene por qué ser la autoridad sobre el movimiento;
• el contacto visual no es lo mismo que el impacto percibido.

Estas distinciones aparecieron repetidamente en los proyectos más sólidos y son más importantes que el logotipo del renderer en el README.

Voxel Musou: el combate en navegador puede tener una verdadera gramática de movimientos

Voxel Musou fue uno de los ejemplos más claros de que el combate en navegador ya no tiene por qué reducirse a una animación de ataque asociada a un botón. Su código fuente está disponible en mike007jd/voxel-musou.

El proyecto utiliza largas cadenas de ataques normales y ramas de ataques cargados en lugar de un combo puramente lineal. Esto importa desde el punto de vista arquitectónico porque el sistema puede modelarse así:

current move + buffered input + combat state -> next move

Esta es una base mucho mejor para un juego de acción centrado en personajes que una colección creciente de condicionales para casos especiales. También muestra ataques aéreos, secuencias especiales, varios kits de personajes, comportamiento de jefes, hit-stop y combate contra grandes grupos de enemigos.

La lección de ingeniería más general es que los movimientos deben convertirse en datos y las transiciones deben hacerse explícitas. Cuando eso ocurre, añadir otro personaje ya no exige reescribir todo el controlador de combate.

Long Wind: lo más parecido a un juego de acción moderno en navegador

Long Wind fue una de las referencias integrales más sólidas porque combina movimiento en tercera persona con ataques ligeros y pesados, fijación de objetivo, guardia, parada perfecta, invulnerabilidad durante la evasión, presión de postura, ejecuciones, reacciones de lanzamiento y derribo, proyectiles, jefes y varios arquetipos de enemigos. El código fuente está disponible en jbang2004/long-wind.

Su valor no está en que cada función individual sea inédita, sino en que todas conviven dentro de un único prototipo de acción nativo del navegador. Eso lo convierte en una referencia útil para seguir todo el recorrido desde la entrada y la selección de objetivo hasta el estado de ataque, la animación, el contacto, la reacción, el hit-stop y el feedback de cámara.

El motion warping resuelve un problema que las demos web suelen ignorar

Samurai Third-Person Template ThreeJS resulta especialmente interesante porque aborda un problema clásico del combate cuerpo a cuerpo en tercera persona. Su código fuente está disponible en achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Una animación de ataque creada previamente asume que el objetivo estará a una distancia concreta cuando el golpe alcance su fotograma de contacto. En un juego real, el objetivo casi nunca está colocado a la perfección. Si el personaje simplemente reproduce la animación en el mismo sitio, la espada puede fallar visualmente aunque el juego aplique daño. Si el personaje se teletransporta a la posición correcta, el ataque parece artificial.

El motion warping ofrece una respuesta mejor: ajustar la rotación y la traslación durante el ataque para que el personaje llegue a la posición de contacto prevista en el momento correcto.

La distinción importante es:

animation intent != movement authority

Un personaje puede conservar la intención visual de una animación creada previamente mientras el controlador de juego sigue teniendo la autoridad sobre el lugar al que realmente se mueve el personaje.

La detección de colisiones y la validación de impactos son problemas distintos

Stick & Steel explora un modelo de combate muy diferente. Su código fuente está disponible en Rabneba/stick-steel.

En lugar de tratar la espada principalmente como una animación con un volumen de daño, el proyecto da presencia física a las armas. Importan la velocidad de contacto, la orientación del arma, la región del cuerpo, las guardias, los choques, los derribos y los desarmes.

La lección más transferible no es que todos los juegos de acción deban usar armas completamente físicas. Es esta:

Una colisión indica que dos cosas se tocaron. No indica si se produjo un impacto significativo.

Un sistema de combate convincente suele necesitar una segunda capa que decida si el contacto tuvo suficiente velocidad, la dirección correcta, la zona correcta del arma, el momento correcto y un estado válido del objetivo como para contar como daño.

Centralizar la resolución del combate facilita razonar sobre defensas complejas

Hollowmere, cuyo código fuente está en euuuuuuan/hollowmere-public, destacó menos por el espectáculo visual y más por su arquitectura de software.

Su simulación de combate está separada del renderizado y la resolución defensiva está centralizada. Esto evita un fallo común en los juegos de acción, donde el sistema de evasión, el sistema de parada, el sistema de reacción a impactos y la capa de animación pueden discrepar de forma independiente sobre si un mismo ataque acertó.

Un modelo mental más limpio es:

incoming attack -> evade | parry | hit

El renderer debería mostrar el resultado, no inventar una segunda versión de la verdad del combate.

Esta distinción se vuelve cada vez más importante a medida que el combate crece. La simulación determinista y las transiciones de estado explícitas no son funciones llamativas, pero facilitan probar, depurar y ampliar sistemas de combate complejos.

La sensación de juego es un sistema de ingeniería, no decoración

Fabled Revolutions, cuyo código fuente está en ericrius1/FabledRevolutions, resulta útil precisamente porque aísla los efectos que hacen que los impactos se sientan contundentes.

Un sistema de combate lógicamente correcto puede seguir sintiéndose débil. La colisión puede ser precisa, el daño puede aplicarse en el fotograma correcto y, aun así, el resultado puede sentirse como dos modelos atravesándose.

El impacto percibido suele surgir de una combinación de efectos de corta duración:

• hit-stop;
• sacudida o golpe de cámara;
• estelas de armas;
• partículas de impacto;
• destello al recibir daño;
• retroceso;
• reacción de animación;
• sonido bien sincronizado.

Esto sugiere otra distinción útil: la corrección del combate no es lo mismo que la sensación del combate. Un juego de navegador necesita ambas cosas.

El renderer no fue el principal predictor de la calidad del combate

Uno de los patrones más interesantes de la investigación fue que el mejor combate no dependía de que un proyecto utilizara la API de renderizado más reciente.

Three.js apareció repetidamente. Algunos proyectos utilizaban tecnología de renderizado relacionada con WebGPU; otros, stacks convencionales basados en WebGL. A lo largo de la investigación aparecieron motores de física, TypeScript, JavaScript, Vite, WebAssembly y distintos enfoques de renderizado.

Pero el combate sofisticado dependía de forma más constante de la arquitectura: simulación con paso fijo, estados explícitos, selección de objetivos fiable, una autoridad de animación bien definida, movimientos basados en datos, resolución de daño centralizada y buen feedback de impacto.

Esto es alentador para los desarrolladores web. No hace falta esperar a que todos los usuarios dispongan del stack gráfico más reciente para experimentar con un diseño de combate serio.

Por qué la distribución mediante navegador cambia la ecuación

El navegador tiene una ventaja que poco tiene que ver con los gráficos: una fricción de distribución extremadamente baja.

Los juegos tradicionales suelen interponer varios pasos entre el descubrimiento y la interacción: encontrar la página de la tienda, descargar un paquete grande, instalarlo, iniciarlo, esperar actualizaciones y, en ocasiones, crear una cuenta antes de llegar a una experiencia de juego significativa.

Un juego de navegador puede reducir ese recorrido a un enlace.

Esto cambia la forma de compartir y probar prototipos. Un desarrollador puede publicar una build, enviar una URL, hacer que otra persona entre inmediatamente en la misma versión, recopilar feedback y desplegar otra iteración sin pedir al tester que instale manualmente un paquete nuevo.

Esta ventaja resulta especialmente importante para juegos experimentales y desarrollo independiente. El navegador no es solo un entorno de ejecución; también es un sistema de distribución.

Dónde sigue perdiendo el navegador

La investigación no me convenció de que los navegadores hayan sustituido a las plataformas de juego nativas. No lo han hecho.

Siguen existiendo varias limitaciones importantes:

• Grandes volúmenes de recursos. El acceso instantáneo deja de sentirse instantáneo cuando un juego necesita una descarga inicial muy grande.
• Presión de memoria. Los navegadores deben coexistir con otras pestañas y con el sistema operativo, y el comportamiento de la memoria es menos predecible que en un proceso nativo dedicado.
• Límites térmicos en dispositivos móviles. Un juego 3D técnicamente funcional puede seguir reduciendo mucho su rendimiento durante una sesión prolongada.
• Diferencias entre navegadores. Los gráficos, el audio, el pointer lock, el modo de pantalla completa, los gamepads y las características de rendimiento no son perfectamente uniformes.
• Preparación de shaders y recursos. El trabajo de compilación o upload todavía puede provocar pausas visibles si el pipeline no está diseñado con cuidado.
• Limitaciones del uso sin conexión y de la persistencia local. Las aplicaciones nativas conservan un control más directo sobre instalaciones locales grandes y archivos.
• Seguridad competitiva. Un sistema antitrampas serio y los supuestos de cliente hostil se vuelven mucho más difíciles cuando el cliente es una aplicación web.

Estas limitaciones importan porque definen dónde son más fuertes hoy los juegos de navegador: juegos que se benefician del acceso inmediato, la iteración rápida, la distribución multiplataforma y presupuestos manejables de recursos y ejecución.

La IA acorta mucho el ciclo de prototipo a URL

La IA es relevante aquí, pero no porque convierta mágicamente una frase en un juego terminado y de alta calidad. La ventaja más realista es la velocidad de iteración.

El desarrollo moderno de juegos contiene muchas tareas pequeñas que, en conjunto, resultan costosas: configurar máquinas de estados, crear vistas de depuración, escribir pruebas, experimentar con comportamientos enemigos, crear formatos de datos para movimientos, refactorizar código de entrada, prototipar shaders, examinar errores de física y conectar contenido temporal.

La IA puede acortar muchos de esos ciclos. Combinada con la distribución web, el flujo de trabajo se vuelve inusualmente directo:

idea -> prototype -> deploy -> open URL -> test -> iterate

El navegador ya hace que el despliegue sea rápido. La IA también puede acelerar la parte de implementación de ese mismo ciclo.

La advertencia importante es que la generación rápida no sustituye el criterio ni la validación. Un controlador de combate generado puede estar estructuralmente mal. La temporización de las animaciones sigue necesitando criterio humano. La física sigue necesitando depuración. El rendimiento sigue necesitando medición. La IA reduce el coste de probar ideas; no elimina la necesidad de decidir cuáles son buenas.

Qué significa esto para los desarrolladores web

La frontera entre el desarrollo web y el desarrollo de juegos se está volviendo menos rígida.

Un juego de navegador serio puede utilizar ahora herramientas web conocidas y, al mismo tiempo, requerir conceptos clásicos de ingeniería de juegos:

• pasos de simulación fijos;
• máquinas de estados;
• buffering de entrada;
• grafos de animación;
• consultas espaciales;
• física;
• presupuestos por fotograma;
• gestión de recursos de GPU;
• temporización de audio;
• sistemas deterministas.

Al mismo tiempo, los desarrolladores de juegos que apuntan al navegador obtienen cosas en las que la web ya es excepcionalmente buena: URLs, despliegue instantáneo, distribución mediante CDN, actualizaciones rápidas, telemetría, sistemas de cuentas, interfaces adaptables y posibilidad de compartir sin fricción.

La investigación cambió mi propio modelo mental. Ya no veo los juegos de navegador principalmente como versiones simplificadas de juegos nativos. Veo el navegador como una plataforma de juegos cada vez más capaz, con un conjunto distinto de fortalezas: distribución inmediata, iteración rápida, capacidades 3D cada vez más serias y un enorme ecosistema de desarrollo ya existente.

La web no solo está mejorando a la hora de mostrar juegos creados en otros entornos. Cada vez se convierte más en un lugar donde los sistemas de juego serios pueden ser diseñados, implementados, probados, distribuidos y jugados directamente.