Lo que realmente hace falta para crear un mundo abierto en un navegador
Por Mariana Muntean, CEO de Cinevva
El equipo de Cinevva acaba de publicar uno de los diarios de ingeniería más transparentes de los últimos tiempos en el desarrollo de videojuegos: una serie de 12 partes que documenta nuestro intento de crear un mundo abierto multijugador que se ejecute íntegramente en el navegador. Sin descargas. Sin tienda de aplicaciones. Solo una URL.
El proyecto abarcó 24 experimentos técnicos que llamamos «spikes»: prototipos breves y específicos, cada uno diseñado para responder una pregunta arriesgada. Todos los spikes se publicaron con código fuente funcional que puedes abrir y ejecutar ahora mismo en tu navegador. La serie fue escrita por Oleg Sidorkin, CTO y cofundador de Cinevva, y se lee menos como marketing y más como un diario de campo desde la primera línea de lo que los navegadores pueden hacer realmente en 2026.
Lo que hace que valga la pena leer la serie —aunque nunca tengas previsto crear sistemas de terreno— es el método que hay detrás. Es un caso práctico sobre cómo reducir el riesgo de un proyecto ambicioso antes de comprometer recursos costosos.
Empezar primero por la pregunta más difícil
La mayoría de los proyectos de mundo abierto fracasan siguiendo una secuencia predecible. Primero tienes un concepto precioso. Después, una escena bonita. Luego descubres que ya habías agotado el presupuesto por fotograma antes incluso de que existiera la jugabilidad.
Nuestro equipo invirtió el orden. El primer spike era feo a propósito: una malla de terreno de 512 metros, 500 objetos instanciados, ruido de altura procedural, un plano de agua y niebla. Sin sombras ni pase de embellecimiento. La única pregunta era si un navegador podía mantener una tasa de fotogramas estable mientras la cámara se desplazaba por el entorno.
Podía. Y ese «sí» estableció lo que Oleg denomina un «contrato de referencia»: un coste medido de una escena mínima que servía como referencia y frente al cual cada función posterior debía justificar su existencia. Si un efecto nuevo se veía genial pero hacía saltar por los aires el presupuesto por fotograma, no se publicaba. Al menos, todavía no.
Ese tipo de disciplina parece obvio. En la práctica, es poco frecuente en entornos de prototipado acelerado donde todo el mundo está entusiasmado con el siguiente logro visual.
La apuesta por las físicas
El segundo experimento abordó un debate arquitectónico que divide a quienes desarrollan juegos para navegador: ¿deben ejecutarse las físicas en el hilo principal, donde es más sencillo, o en un Web Worker, donde no pueden bloquear el renderizado?
Sobre el papel, ejecutar las físicas en un worker es una solución más limpia. En la práctica, preocupa la latencia. Cada evento de entrada debe cruzar dos veces el límite de mensajería: una para llegar al worker y otra para devolver el resultado. Si ese viaje de ida y vuelta es demasiado lento, pulsar una tecla y ver cómo se mueve el personaje se sentirá pesado.
El equipo integró el motor de físicas Rapier —compilado de Rust a WebAssembly— en un worker dedicado, conectó el canal de mensajes y realizó mediciones. La sobrecarga era insignificante. Los controles seguían respondiendo de inmediato. Sin embargo, tuvimos cuidado de señalar que habíamos validado un escenario específico, no una regla universal. Cuando más adelante cambiaran la carga de la GPU y la complejidad del streaming, habría que volver a comprobar las suposiciones.
Los spikes aburridos que salvaron el proyecto
La tercera parte de la serie no incluye capturas de pantalla. Trata sobre tres experimentos poco glamurosos, pero con consecuencias a nivel de producto.
El primero comprobó si los Durable Objects de Cloudflare podían gestionar emisiones de posición en tiempo real con frecuencias de actualización propias de un juego: la columna vertebral del multijugador. Si hubiera fallado, toda la arquitectura de red habría necesitado una fragmentación temprana en lugar de asignar cada isla a una única instancia.
El segundo validó un perfil de calidad para móviles: no un ajuste de escritorio con otro nombre, sino una ruta de renderizado explícita y de bajo coste basada en la misma línea base de terreno. La pregunta era si el mundo podía seguir siendo legible y reactivo bajo las limitaciones de las GPU móviles sin tener que reescribir el renderizador.
El tercero evaluó si los scripts de comportamiento generados por IA para los flujos de trabajo de los creadores serían lo bastante fiables para usarlos en producción.
Ninguno produjo vídeos espectaculares. Los tres fijaron límites estrictos que dieron forma a todas las decisiones arquitectónicas posteriores. Oleg escribe que estos «spikes poco vistosos cambiaron la arquitectura más rápido que los spikes visuales».
Streaming: donde los proyectos bonitos se desmoronan
Puedes ocultar muchas cosas en una imagen estática. No puedes ocultar un tirón de 40 milisegundos al cruzar el límite de un chunk mientras corres.
El equipo probó el streaming antes de crear terreno avanzado, separando deliberadamente las distintas cuestiones. El Spike 6 validó la carga de chunks vecinos con contenido sencillo. Solo después de obtener esa señal clara, el Spike 11 introdujo el streaming de mapas de altura comprimidos con refinamiento progresivo: primero cargaba el terreno con una resolución de 17 muestras, después con 33 y, por último, con la cuadrícula completa de 65 muestras.
La secuencia importó más de lo que esperábamos. Si hubiéramos empezado directamente con chunks de altura comprimidos, cada tirón habría sido ambiguo. ¿Era un problema de decodificación, un bloqueo al subir texturas o un problema al actualizar la geometría? Probar primero el streaming sencillo eliminó toda una categoría de incertidumbre.
De ahí surgió una lección práctica: hay que medir directamente los bloqueos de subida, no inferirlos a partir de los FPS medios. Los promedios ocultan los picos en los tiempos de fotograma, y esos picos son lo que los jugadores realmente perciben.
Las guerras por el presupuesto visual
Tres experimentos distintos atacaron los costes de renderizado de forma aislada, en vez de agruparlos. La densidad de la vegetación y su animación por el viento. Materiales de terreno multicapa con mapeado triplanar para las paredes de los acantilados. Mapas de sombras en cascada bajo una carga de terreno realista.
El spike de vegetación reveló que agrupar las instancias en menos mallas importaba más que reducir la cantidad de polígonos de cada brizna. El spike de materiales determinó que la proyección triplanar sobre superficies verticales justificaba su coste de GPU, pero añadir una quinta capa de mezcla de texturas no. El spike de sombras concluyó que tres cascadas con una resolución de 1024 proporcionaban sombras de contacto aceptables sin superar los 2 milisegundos de tiempo de GPU.
El equipo adoptó una regla tajante: una función solo avanza si puede justificar su coste con datos medidos del tiempo de fotograma. Esa restricción, fijada desde el principio, simplificó considerablemente las decisiones arquitectónicas posteriores en torno al terreno volumétrico y los clipmaps.
El giro que cambió la trayectoria del proyecto
Antes del Spike 10, nuestro modelo mental era «un mundo más grande implica más geometría». Después del Spike 10, pasó a ser «presupuesto de geometría constante y actualización de anillos centrados en la cámara».
Los clipmaps de geometría —anillos concéntricos de terreno centrados en la cámara, cada vez menos detallados— permitían mantener aproximadamente constante la cantidad de triángulos, sin importar la distancia de dibujado. El truco práctico consistía en aplicar geomorphing en los límites de los anillos: mezclar suavemente las alturas de los vértices en el shader para que la transición entre niveles de resolución fuera invisible durante el movimiento.
La metodología de pruebas nos enseñó una lección sutil. Los clipmaps se ven bien en las capturas de pantalla. Sus artefactos solo aparecen durante un movimiento sostenido de la cámara a través de los límites de los anillos. El equipo dedicó tiempo a realizar recorridos a velocidad constante y observar si aparecía ruido temporal. «Las capturas de pantalla mentían», escribe Oleg. «El movimiento decía la verdad».
Adentrarse bajo tierra
Los mapas de altura no pueden representar cuevas. Almacenan un único valor de elevación por cada punto de una cuadrícula. En cuanto necesitas túneles, salientes o paredes de roca excavadas, necesitas terreno volumétrico.
El Spike 12 implementó marching cubes en la GPU mediante shaders de cómputo de WebGPU, extrayendo mallas triangulares de un campo de distancia con signo tridimensional. Cuatro chunks de 64³ se ejecutaban simultáneamente, con actualizaciones de la malla en cada fotograma a partir de modificaciones animadas del SDF. El shader de cómputo se encargaba de todo —evaluar el campo, clasificar las celdas y emitir los vértices— sin ninguna lectura de vuelta en la CPU.
El reto no era conseguir que funcionara. Era lograr que funcionara junto con todo lo demás. La integración con el grafo de escena de Three.js, la gestión del ciclo de vida de los búferes —los búferes de WebGPU no pueden redimensionarse— y el manejo de fences para evitar destruir recursos de GPU que aún estaban en uso: la serie dedica dos partes completas a lo que llamamos «robustecimiento incremental», el proceso poco glamuroso de añadir una capacidad cada vez y comprobar que la capa anterior sigue funcionando después de cada incorporación.
La pesadilla de las uniones
La sección técnicamente más angustiosa de la serie abarca las partes 9 a 11 y explica qué ocurre cuando se encuentran chunks de terreno con resoluciones diferentes.
Cuando un chunk de alta resolución se encuentra junto a uno de baja resolución, sus mallas generadas de forma independiente no se alinean en el límite. El resultado son grietas visibles, bordes parpadeantes y uniones en T por las que se filtra la luz. El algoritmo Transvoxel lo resuelve con celdas de transición especiales que salvan las diferencias de resolución, pero implementarlo correctamente en todas las configuraciones de chunks, con un orden de orientación coherente, una gestión adecuada de los búferes y rangos de dibujado precisos, requirió seis experimentos distintos.
La historia de depuración más memorable del equipo: pasamos dos días persiguiendo un artefacto en una unión que atribuíamos a la lógica de transición. El verdadero culpable eran datos obsoletos. El shader de cómputo de la GPU escribía N vértices en un búfer, pero la llamada de dibujado seguía configurada para renderizar N+M vértices del fotograma anterior. Esos vértices adicionales contenían basura que producía triángulos parpadeantes, finos como cuchillas. La solución fue una sola línea: limitar el rango de dibujado al número de vértices activos indicado por el contador atómico.
«Los errores de renderizado suelen hacerse pasar por errores de generación de mallas», observa Oleg. «La geometría había sido correcta todo el tiempo».
Del caos a la gobernanza
Después de la batalla con las uniones, el equipo sustituyó el comportamiento improvisado de los chunks por un sistema explícito de políticas. A partir de entonces, una función central decidía el nivel de LOD de cada chunk, el modo de renderizado —mapa de altura o marching cubes— y qué caras necesitaban celdas de transición. Los anillos de distancia determinaban el LOD base. Una restricción de adyacencia garantizaba que dos chunks vecinos no difirieran en más de un nivel de resolución. Un mapa de bits de ediciones mantenía los chunks volumétricos en modo marching cubes independientemente de la distancia si contenían modificaciones de creadores.
Las superposiciones de depuración codificadas por colores —verde para los chunks de mapa de altura, azul para los de marching cubes y naranja para las caras de transición— convirtieron «vi un error en algún lugar cerca de esa cresta» en «el error aparece en la posición (142, 12, -67), mirando hacia el noroeste».
«La política no redujo la complejidad», escribe Oleg. «Organizó la complejidad».
El resultado final
El último spike combinó anillos de clipmap, niebla celeste por fragmento —muestreando el color real del skybox en la dirección de cada fragmento de terreno— y la conexión de módulos de Three.js en una demostración unificada. El resultado es un sistema de terreno que superpone edición volumétrica en el campo cercano, chunks de mapas de altura a media distancia y anillos de clipmap en la lejanía, bajo una capa de políticas que gobierna el modo, el LOD y las transiciones.
La serie concluye con varias lecciones que Oleg afirma que repetiría en cualquier proyecto futuro:
- Empieza con spikes de riesgo antes de trabajar en funciones. Resuelve las preguntas del tipo «¿podemos hacer esto siquiera?» antes de invertir en pipelines de contenido.
- Congela líneas base que sabes que funcionan antes de dar grandes saltos de integración. El día dedicado a establecer un punto de control limpio ahorra varios días posteriores buscando regresiones mediante bisección.
- Impón políticas y observabilidad antes de emprender maratones de optimización. Las condiciones identificadas y acompañadas de reglas de activación siempre superan a los errores misteriosos.
- Haz pruebas en movimiento, no con capturas de pantalla. Los saltos, el parpadeo y los tirones del streaming se esconden en las imágenes estáticas.
- Mide el tiempo de fotograma de cada función, no los FPS medios. Los promedios ocultan los picos que los usuarios perciben realmente.
- Publica las partes desordenadas. Los caminos equivocados, la búsqueda de fantasmas y los dos días culpando al sistema incorrecto. Esas son las partes de las que la gente puede aprender de verdad.
Por qué esto importa más allá de Cinevva
La serie es importante por tres motivos que trascienden el pipeline de terreno de una sola empresa.
En primer lugar, demuestra que los shaders de cómputo de WebGPU, las físicas con WebAssembly y los Durable Objects desplegados en el edge han cruzado un umbral. En 2026, un mundo abierto multijugador con terreno volumétrico, edición en tiempo real y LOD por streaming es arquitectónicamente viable en una pestaña del navegador. Hace dos años no lo era.
En segundo lugar, la metodología de spikes —experimentos pequeños y específicos, cada uno de los cuales responde una pregunta arriesgada mediante resultados funcionales y medibles— ofrece un modelo para cualquier equipo que intente hacer algo que podría no funcionar. La disciplina de medir antes de comprometerse, establecer líneas base antes de integrar e identificar los casos límite antes de optimizar se aplica mucho más allá de los sistemas de terreno.
En tercer lugar, la transparencia radical es precisamente el objetivo. Publicar el código fuente de los 24 experimentos, incluidos los callejones sin salida y los desvíos de depuración de dos días, convierte esto en algo más que un blog técnico. Es un cuaderno público de ingeniería que trata al lector como a un colega y no como a un cliente. La serie completa está disponible en nuestra guía de la serie, con todos los prototipos ejecutándose en vivo en el navegador.
Este artículo se publicó originalmente en Medium.