Tecnología de mundos abiertos 3D en el navegador para mundos multijugador de creadores

Queremos reunir a nuestros creadores en un mundo abierto compartido. No en una sala de espera. No en una galería. En un espacio 3D vivo donde la gente pueda explorar, construir y descubrir por casualidad las creaciones de otros. Algo que se cargue en una pestaña del navegador y se sienta como un lugar en el que merezca la pena estar.

Es un problema difícil. Skyrim y The Witcher 3 invirtieron cientos de millones de dólares en construir sus mundos, y aun así se ejecutan en hardware dedicado y ocupan decenas de gigabytes en disco. Nuestro objetivo es una pestaña del navegador, un estado compartido entre cientos de jugadores y un mundo que los creadores puedan transformar de verdad.

Esta guía documenta lo que descubrimos al investigar la tecnología. Qué es posible hoy, qué está por llegar y qué arquitectura nos permitiría conseguirlo.

Qué podemos aprender de Skyrim y The Witcher

Antes de elegir una tecnología, conviene entender cómo funcionan realmente dos de los mundos abiertos más exitosos. Sus técnicas se adaptan sorprendentemente bien a las limitaciones del navegador.

El sistema de celdas de Skyrim

El mundo abierto de Skyrim carga por streaming una cuadrícula de 5x5 celdas alrededor del jugador. Las montañas lejanas son impostores de baja resolución. Nunca lo notas.

Skyrim divide su mundo en una cuadrícula de 57x37 celdas exteriores, cada una de 4096x4096 unidades de juego (aproximadamente 59 metros). El motor mantiene cargada en todo momento una cuadrícula de 5x5 celdas alrededor del jugador. A medida que avanzas, las celdas del borde trasero se descargan mientras se cargan por streaming las del borde delantero. Los espacios interiores (mazmorras y edificios) son espacios de mundo independientes que se cargan mediante activadores situados en las puertas.

Esto se puede aplicar directamente a un mundo en el navegador. No se carga el mapa completo. Se carga una zona alrededor del jugador y se sustituyen los fragmentos a medida que este se desplaza. La idea clave: Skyrim nunca permite ver con todo detalle el terreno lejano. Utiliza un enfoque multirresolución.

Niveles de LOD (nivel de detalle) en Skyrim:

• Detalle completo en un radio de 1-2 celdas (el área inmediata del jugador)
• Mallas simplificadas a media distancia (los objetos pierden la geometría más pequeña)
• Impostores en forma de billboard para árboles y rocas situados más allá de la distancia media
• El LOD del terreno utiliza mallas de baja resolución precalculadas para los paisajes lejanos
• Distancias de desvanecimiento ajustadas para cada objeto (la hierba desaparece primero y los edificios, al final)

El paisaje de Skyrim utiliza un terreno basado en mapas de altura con parches de 32x32 vértices por celda. Cada parche puede tener distintas texturas mezcladas mediante mapas alfa. Esto requiere poco almacenamiento y es barato de renderizar. Los datos de terreno de una sola celda se miden en kilobytes, no en megabytes.

Qué podemos aplicar: Streaming basado en fragmentos, terreno con mapas de altura, LOD agresivo, separación entre interiores y exteriores, y la idea de que el terreno lejano no necesita ser geométricamente preciso, sino solo visualmente convincente.

La arquitectura de streaming de The Witcher 3

El mundo de 136 km² de The Witcher 3 utiliza streaming basado en el contenido. Los árboles situados a más de 200 m son impostores planos. Los edificios se cargan por streaming de forma independiente al terreno.

El mundo de The Witcher 3 es más grande que el de Skyrim (aproximadamente 136 km² entre todas sus regiones) y utiliza un sistema de streaming más sofisticado. CD Projekt RED creó un motor propio (REDengine 3) en el que el mundo se divide en sectores de streaming, no en una cuadrícula estricta.

Cada sector contiene una jerarquía de capas de contenido:

• Terreno cargado por streaming en forma de parches con 4 niveles de LOD
• Vegetación que utiliza instanciación en la GPU con descarte basado en la distancia
• Geometría estática (edificios y rocas) cargada por streaming de forma independiente al terreno
• Objetos de juego (NPC, objetos y activadores) que se cargan según el estado de las misiones y la proximidad

El renderizador utiliza sombreado diferido con materiales basados en principios físicos. Un truco especialmente relevante: The Witcher 3 utiliza impostores de forma muy agresiva. Un árbol situado a 200 metros no es un modelo 3D con ramas y hojas. Es un cuadrilátero plano con textura que siempre mira hacia la cámara. El motor prerenderiza estos impostores desde varios ángulos y los intercambia a medida que se mueve la cámara. Nunca lo notas porque están lo bastante lejos.

Composición del mundo: El mundo abierto de The Witcher 3 se construyó por capas mediante equipos independientes que trabajaban simultáneamente. El equipo de terreno esculpió el paisaje. El equipo de arte de entornos colocó las estructuras. El equipo de misiones configuró los activadores y las rutas de los NPC. Este sistema de composición por capas permitió que un equipo grande trabajara sin interferir en el trabajo de los demás.

Qué podemos aplicar: Composición del mundo por capas (fundamental para una plataforma de creadores), renderizado mediante impostores para objetos lejanos, renderizado diferido para numerosas fuentes de luz y la idea de que el streaming debe tener en cuenta el contenido (no cargar interiores que no se pueden ver ni generar NPC que no estén cerca).

El motor químico de Breath of the Wild

BotW funciona en hardware comparable al de una tableta y tiene un aspecto impresionante. Estilo cel shading, niebla distante tipo acuarela e interacciones sistémicas en lugar de contenido guionizado. El referente de los mundos abiertos estilizados.

El enfoque de Nintendo para el diseño de mundos abiertos invirtió la fórmula habitual. En lugar de llenar el mundo con contenido guionizado, crearon reglas sistémicas y permitieron que los jugadores descubrieran comportamientos emergentes. El fuego se propaga por la hierba. El metal conduce la electricidad durante las tormentas. El viento transporta objetos. Todo interactúa con todo lo demás mediante una capa coherente de física y química.

Esto es importante para un mundo de creadores porque sugiere que el propio mundo puede resultar más interesante que cualquier objeto colocado de forma individual. Si los creadores pueden definir propiedades de materiales y reglas de interacción (en lugar de limitarse a colocar mallas estáticas), el mundo adquiere comportamientos emergentes que hacen que merezca la pena explorarlo incluso en zonas que nadie ha diseñado expresamente.

Conclusiones técnicas de BotW:

• Un número de polígonos y una resolución relativamente bajos (900p con la Switch conectada a la base). El aspecto estilizado con cel shading oculta la baja fidelidad. Hoy, un mundo en el navegador podría alcanzar una calidad visual similar.
• El renderizado a distancia utiliza una niebla con sombreado tipo dibujo animado que se desvanece en skyboxes con estilo de acuarela. Es barata de renderizar y se ve preciosa en la práctica. Este tipo de perspectiva atmosférica es prácticamente gratuito en un sombreador de fragmentos.
• El mundo ocupa aproximadamente 84 km², pero es poco denso. La mayor parte del mapa es terreno transitable con puntos de interés distribuidos por él. El contenido denso se reserva para pueblos y santuarios. Este enfoque «disperso pero interesante» reduce drásticamente los requisitos de recursos en comparación con la densamente poblada Novigrado de The Witcher 3.
• Los objetos físicos tienen etiquetas de material (madera, metal, comida o explosivo) que determinan sus interacciones. El número de reglas reales es reducido (quizá entre 20 y 30 tipos de interacción), pero se combinan de formas que parecen infinitas.

Las capas del mundo de GTA V

Los Santos de GTA V parece una ciudad viva gracias a sus sistemas ambientales por capas: tráfico, peatones, ciclo diario y clima. Los edificios lejanos son fotografías compuestas, no modelos 3D.

El enfoque de Rockstar para Los Santos ofrece una lección diferente. El mundo de GTA V parece estar vivo gracias a sus sistemas ambientales por capas, no porque cada NPC tenga una misión.

La ciudad tiene sistemas de tráfico que simulan cientos de vehículos sobre una red vial. Los peatones siguen rutas, reaccionan al jugador e interactúan entre sí. La hora del día cambia la densidad de población, los tipos de NPC presentes y la actividad ambiental. El clima afecta a la física de conducción y al comportamiento de los NPC.

Para un mundo de creadores, la idea clave es que la vida ambiental marca la diferencia entre un mundo que parece un museo y otro que parece un lugar real. Incluso comportamientos sencillos (pájaros que vuelan por encima, olas que rompen en la orilla o NPC que caminan entre edificios) crean la ilusión de un mundo vivo.

Conclusiones técnicas de GTA V:

• El mapa ocupa 75 km² y utiliza un LOD agresivo combinado con un sistema de streaming que carga contenido según la velocidad (al conducir rápido se carga contenido situado más adelante que al caminar).
• GTA Online reúne simultáneamente a 30 jugadores en este mundo. Incluso con 30, Rockstar descubrió que necesitaba gestionar el interés espacial: recibes actualizaciones detalladas sobre los jugadores cercanos y actualizaciones menos frecuentes sobre los más lejanos. El mismo principio se aplica a nuestro objetivo de 200 jugadores.
• La cadena de producción de recursos de GTA V es una de las más eficientes jamás creadas. El juego completo ocupa aproximadamente 80 GB gracias a una compresión extrema de texturas, al uso compartido de mallas y al detalle procedimental. Los interiores de sus edificios reutilizan ampliamente piezas modulares.
• El juego utiliza un sofisticado sistema de impostores en el que los edificios lejanos son en realidad fotografías planas combinadas entre sí. El jugador nunca lo nota porque las distancias de transición están ajustadas para ángulos de visión concretos.

El mundo abierto continuo de Elden Ring

El mapa de 79 km² de Elden Ring combina terrenos abiertos poco densos con mazmorras detalladas creadas a mano. Los mismos recursos ambientales aparecen por todas partes con distintas disposiciones. La repetición desaparece cuando varían la composición y la iluminación.

FromSoftware creó Elden Ring sobre el mismo motor que Dark Souls, pero lo amplió para construir un mundo abierto. El resultado es interesante porque demuestra cómo un equipo relativamente pequeño (en comparación con Rockstar o CD Projekt) puede crear un gran mundo abierto.

El truco está en variar la densidad. El mapa de Elden Ring es enorme (aproximadamente 79 km²), pero grandes secciones son terrenos abiertos con enemigos y puntos de interés dispersos. El contenido denso creado a mano (las mazmorras de legado, como el Castillo de Velo Tormentoso) está integrado en el mundo abierto y utiliza la misma separación entre interiores y exteriores que Skyrim.

Conclusiones técnicas de Elden Ring:

• El mundo se carga por streaming en grandes teselas. A caballo se puede ver a gran distancia, pero el terreno lejano está extremadamente simplificado. De cerca, el nivel de detalle es comparable al de Dark Souls 3.
• Las pantallas de carga solo aparecen al viajar rápidamente o al entrar en determinadas mazmorras. El propio mundo abierto se carga por streaming sin interrupciones.
• El juego reutiliza ampliamente los recursos ambientales. Los mismos modelos de árboles, formaciones rocosas y piezas de ruinas aparecen por todo el mapa con distintas disposiciones. Con suficiente variedad en la disposición y la iluminación, la repetición pasa desapercibida. Esto se puede aplicar directamente a un mundo de creadores, donde una biblioteca de piezas modulares puede generar una variedad infinita.
• El modo multijugador se basa en sesiones (se invoca a otros jugadores para que entren en tu mundo), no es persistente. Sin embargo, las funciones asíncronas (mensajes, manchas de sangre y fantasmas de otros jugadores) crean una sensación de existencia compartida sin la sobrecarga de red de un servidor persistente. Sería barato añadir estas funciones multijugador ambientales a un mundo en el navegador.

No Man's Sky: todo procedimental

18 trillones de planetas generados a partir de semillas compartidas. Todos los jugadores ven el mismo universo sin almacenarlo en un servidor. Los datos de construcción de bases son compactos: identificadores de piezas más transformaciones.

No Man's Sky es el caso extremo de generación procedimental. 18 trillones de planetas generados a partir de una semilla compartida, de modo que todos los jugadores ven el mismo universo sin que nada de él esté almacenado en un servidor.

La cadena de generación funciona por etapas: las semillas de nivel galáctico determinan las posiciones de las estrellas; las semillas estelares determinan el número y los tipos de planetas; y las semillas planetarias controlan la generación del terreno (ruido de varias octavas), la asignación de biomas, las especies de flora y fauna, las paletas de colores y la distribución de recursos. Todo se calcula de forma determinista a partir de la semilla, por lo que dos jugadores que visiten las mismas coordenadas verán el mismo planeta sin intercambiar ningún dato planetario. Conclusiones técnicas de No Man's Sky:

• La generación de terreno utiliza marching cubes basados en vóxeles con una pila de funciones de ruido. Esto permite crear cuevas, salientes e islas flotantes que los terrenos basados en mapas de altura no pueden representar. La contrapartida es un mayor coste computacional por chunk, pero el resultado es un terreno visualmente más interesante.
• El sistema de construcción de bases es lo más parecido a lo que imaginamos. Los jugadores colocan estructuras que persisten en el servidor y son visibles para otros jugadores. Los datos de las bases son compactos (una lista de piezas con posiciones y rotaciones) y se transmiten bajo demanda cuando alguien visita el planeta.
• Al principio, el juego fue criticado por ofrecer contenido repetitivo pese a su variedad infinita. La generación basada en semillas puede producir terreno infinito, pero pocas sorpresas. La lección: la generación procedimental funciona como lienzo, pero el contenido colocado por los creadores es lo que hace que un lugar parezca diseñado e intencionado.
• Hello Games añadió el multijugador años después del lanzamiento. Hasta 32 jugadores comparten una sesión con construcción y exploración completas. El modelo de red es sencillo: un jugador actúa como anfitrión y los demás se conectan. Para un mundo en el navegador con estado persistente, funciona mejor un modelo con servidor autoritativo, pero No Man's Sky demuestra que los mundos procedimentales compartidos son viables.

Minecraft: el modelo para los mundos de creadores

300 millones de copias vendidas. Texturas de 16x16 píxeles. Terreno totalmente editable. Generación infinita. Multijugador. La referencia más importante para un mundo de creadores. Los clones para navegador demuestran que el concepto funciona en WebGL.

Minecraft es el referente más importante para lo que estamos construyendo, más que cualquier título AAA de gran calidad gráfica. 300 millones de copias vendidas. El mundo se genera de forma infinita, es totalmente destructible y admite multijugador. En Minecraft, los creadores no se limitan a colocar objetos. Remodelan el propio terreno.

Conclusiones técnicas de Minecraft:

• El mundo está dividido en chunks de bloques de 16x16x384. Solo se cargan los chunks cercanos al jugador (la distancia de renderizado es configurable). Es el mismo patrón de streaming de chunks que Skyrim, pero con terreno totalmente editable.
• Cada chunk se almacena como una matriz de identificadores de bloques comprimida mediante una paleta. Un chunk con solo 5 tipos de bloque diferentes almacena un índice de paleta de 4 bits por bloque en lugar de un identificador de bloque completo. Esto hace que los datos de los chunks sean muy compactos (normalmente, entre 10 y 50 KB por chunk después de la compresión).
• El protocolo multijugador de Minecraft está bien documentado y es relativamente sencillo. El servidor envía los datos de los chunks a medida que el jugador se desplaza. Los cambios en los bloques se difunden como pequeñas actualizaciones diferenciales (posición + nuevo tipo de bloque). Este es exactamente el modelo que usaríamos para las modificaciones de los creadores.
• El juego funciona en Java y ahora cuenta con una Bedrock Edition en C++. Existen clones de Minecraft para navegador (ClassiCube, eaglercraft) que demuestran que el concepto básico funciona en WebGL. Normalmente mantienen una distancia de renderizado de entre 8 y 12 chunks a 60 fps, lo que ofrece una vista de unos 200 a 400 metros.
• El ecosistema de mods de Minecraft es su verdadera ventaja competitiva. Los mods añaden nuevos bloques, entidades, biomas y sistemas de juego. Para un mundo de creadores, esto sugiere que la extensibilidad es tan importante como la experiencia base. Si los creadores pueden definir nuevos tipos de interacción (y no solo colocar objetos), el mundo se enriquece con el tiempo.
• Redstone (el sistema de cableado de Minecraft dentro del juego) demuestra que los creadores construirán sistemas complejos si se les proporcionan elementos básicos simples y combinables. Puertas lógicas, granjas automáticas, calculadoras. Un conjunto sencillo de reglas genera una complejidad extraordinaria. Es la misma lección que ofrece el motor químico de BotW.

Patrones comunes en los mundos abiertos AAA

Al analizar todos estos títulos, se repiten los mismos patrones:

La partición espacial es universal. Ya sean celdas (Bethesda), sectores (CD Projekt), chunks (Mojang/Rockstar) o teselas (FromSoftware), todos los mundos abiertos dividen el espacio en unidades cargables. Ningún motor intenta mantener el mundo entero en memoria.

Todo tiene múltiples resoluciones. El terreno, las mallas, las texturas e incluso el audio tienen varios niveles de calidad. La resolución que se obtiene depende de la proximidad y de la importancia del objeto.

El descarte por oclusión importa más que la capacidad bruta de procesar triángulos. No renderizar lo que no se puede ver ahorra más recursos que optimizar lo que sí se ve. Skyrim utiliza un sencillo sistema basado en la distancia. The Witcher 3 emplea oclusión por software con grandes oclusores (edificios y acantilados). Los motores modernos, como Nanite de UE5, llevan esto más lejos con consultas de oclusión por hardware.

La carga asíncrona oculta las transiciones. Estos juegos no muestran pantallas de carga en el mundo abierto (solo al viajar rápidamente o al pasar a interiores). Cargan contenido en hilos en segundo plano, lo descomprimen en paralelo e incorporan gradualmente el nuevo contenido.

Dirección artística antes que número de polígonos. Skyrim salió en 2011 con unos gráficos que ya entonces eran modestos. BotW funciona en un chip propio de una tableta y tiene un aspecto precioso. Minecraft utiliza texturas de 16x16 píxeles y es uno de los juegos visualmente más reconocibles de la historia. Para un mundo en el navegador, esto es enormemente importante. Un estilo artístico bien dirigido con menor fidelidad siempre superará a un mundo técnicamente avanzado pero artísticamente plano.

El diseño sistémico supera al contenido guionizado. El motor químico de BotW, las interacciones entre bloques de Minecraft y los sistemas de tráfico de GTA V generan comportamientos emergentes a partir de reglas sencillas. Es más barato de desarrollar y ejecutar, y genera más historias para los jugadores que las secuencias guionizadas creadas a mano. En un mundo de creadores, el diseño sistémico significa que el mundo sigue siendo interesante incluso en zonas que nadie ha diseñado expresamente.

El contenido colocado por los creadores necesita persistencia y visibilidad. Las bases de Minecraft y No Man's Sky, así como las propiedades de GTA Online, persisten entre sesiones y son visibles para otros jugadores. El modelo de datos del contenido de los creadores siempre es compacto (identificadores de piezas + transformaciones), mientras que su representación visual es rica (el cliente expande los datos para crear escenas 3D completas).

Renderizado: ¿qué puede hacer realmente un navegador?

Three.js

Three.js es la base. Cuenta con la comunidad más grande (más de 100 000 estrellas en GitHub), el mayor número de ejemplos y la compatibilidad más amplia. Abstrae WebGL 2 y ofrece compatibilidad experimental con WebGPU mediante WebGPURenderer.

Para un mundo abierto, Three.js ofrece:

• Renderizado por instancias para vegetación, rocas y geometría repetida (InstancedMesh)
• Sistema LOD integrado (THREE.LOD intercambia mallas según la distancia)
• Descarte por frustum automático por objeto
• Terreno mediante BufferGeometry personalizada o PlaneGeometry basada en mapas de altura
• Materiales PBR mediante MeshStandardMaterial y MeshPhysicalMaterial
• Posprocesado mediante EffectComposer (resplandor, SSAO y mapeo tonal)
• Mapas de sombras, con posibilidad de implementar mapas de sombras en cascada mediante código personalizado
• glTF/GLB como formato principal de recursos (compacto y listo para la GPU)

Three.js también cuenta con un ecosistema activo de herramientas relevantes para los mundos abiertos. three-mesh-bvh acelera el raycasting y las consultas espaciales sobre mallas complejas. postprocessing (de vanruesc) ofrece una pila de posprocesado con mejor rendimiento que la integrada en Three. three-gpu-pathtracing permite obtener renderizados con calidad de referencia.

Limitaciones para mundos abiertos: Three.js no incluye un grafo de escena integrado capaz de gestionar el streaming, la administración de LOD o la partición espacial a gran escala. Hay que construirlos por cuenta propia. Tampoco incluye un sistema de entidades y componentes (ECS), física ni un sistema de terreno. Es un renderizador, no un motor. Esto supone en realidad una ventaja para un mundo abierto personalizado, porque permite controlar la distribución de la memoria y la estrategia de carga, pero implica más trabajo inicial.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js es el otro gran candidato. Con el respaldo de Microsoft, ofrece más funciones integradas que Three.js para el problema específico de los mundos abiertos.

Funciones integradas relevantes:

• Partición de escenas basada en octrees para un descarte eficiente en escenas grandes
• Sistema de partículas sólidas para renderizado masivo por instancias
• Terreno a partir de mapas de altura con LOD integrado y mezcla de múltiples texturas
• Editor de materiales por nodos para crear shaders visualmente
• Compatibilidad con WebGPU (más madura que la de Three.js, ya que Babylon invirtió antes)
• Integración con la física de Havok (compilada en Wasm y con calidad de producción)
• Streaming de glTF con carga progresiva

La extensión DynamicTerrain de Babylon genera chunks de terreno sobre la marcha a partir de datos de mapas de altura, gestiona el LOD automáticamente y admite la mezcla de texturas. Esto se acerca mucho más a lo que hace Skyrim que cualquier función que Three.js ofrezca de fábrica.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

La contrapartida: Babylon.js es una biblioteca más grande (la compilación completa ocupa aproximadamente entre 1 y 2 MB minificada, frente a los cerca de 600 KB de Three.js). Sin embargo, para un mundo abierto probablemente se añadiría suficiente código personalizado a Three.js como para que la diferencia de tamaño fuese insignificante. Babylon también cuenta con su propio sistema Node Material, inspector y herramientas de desarrollo, que aceleran la iteración.

Babylon.js 8.0 (publicado en marzo de 2025) reforzó su candidatura como núcleo del motor. Todos los shaders principales del motor ahora se distribuyen tanto en GLSL como en WGSL, por lo que WebGPU funciona sin capa de conversión y el paquete de WebGPU ocupa aproximadamente la mitad que antes. La misma versión incorporó al motor el controlador de personajes completo de Havok, luces de área, un motor de audio reconstruido y mejoras en el splatting gaussiano (formatos SPZ y PLY comprimido, armónicos esféricos y menor consumo de memoria y CPU).

PlayCanvas

Vale la pena mencionar PlayCanvas porque es el motor 3D concebido para la web con mayor trayectoria en producción. Snap, Facebook y numerosos clientes publicitarios han lanzado con él experiencias 3D complejas. El motor ocupa alrededor de 1 MB, carga rápidamente y su editor en la nube permite crear mundos de forma colaborativa.

Para un mundo abierto en particular, PlayCanvas ofrece grupos de procesamiento por lotes para optimizar las llamadas de dibujo, un generador de mapas de iluminación integrado y compatibilidad con splatting gaussiano (relevante para entornos del mundo real capturados mediante fotogrametría). El entorno de ejecución es ligero y está bien optimizado para navegadores móviles.

WebGPU: la clave del rendimiento

WebGPU cambia las reglas para los mundos abiertos en el navegador. Las dos funciones más importantes son:

Los shaders de cómputo permiten generar terreno, colocar vegetación, simular partículas e incluso ejecutar física sencilla en la GPU. En un mundo WebGL, todo esto se ejecuta en la CPU mediante JavaScript. Con WebGPU, es posible generar secciones de terreno enteramente en la GPU, calcular las transiciones de LOD en la GPU y ejecutar pasadas de descarte en la GPU. Esto libera la CPU para las comunicaciones de red, la lógica del juego y el streaming de contenido.

El renderizado indirecto permite que la GPU decida qué dibujar a partir de la salida de un shader de cómputo. Se envía una sola llamada de dibujo y la GPU decide cuántas instancias renderizar para cada nivel LOD en función de la distancia. Así gestionan los motores modernos millones de briznas de hierba o árboles. Sin renderizado indirecto (que WebGL no admite), la CPU tiene que ordenar y agruparlo todo, lo que se convierte en el cuello de botella en escenas densas.

WebGPU ya está disponible en todos los navegadores principales. Chrome y Edge lo incluyen desde la versión 113, Firefox lo añadió en Windows (141) y macOS con Apple Silicon (145), y Safari 26 lo incorporó a macOS, iOS, iPadOS y visionOS a finales de 2025. Esto sitúa la compatibilidad global en torno al 82 %, incluidos los dispositivos móviles (Chrome para Android y Samsung Internet también lo incluyen). Aun así, convendría mantener WebGL 2 como alternativa para navegadores antiguos y dispositivos donde WebGPU no esté habilitado, pero la brecha se ha reducido rápidamente.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

Pila de renderizado recomendada

Para un mundo abierto en el navegador dirigido a creadores en equipos de escritorio:

Opción principal: Three.js o Babylon.js con renderizador WebGPU cuando esté disponible y WebGL 2 como alternativa. Babylon ofrece mejores elementos integrados para mundos abiertos. Three.js cuenta con una comunidad más grande y mayor flexibilidad.

Nuestra elección: Babylon.js como núcleo del motor por su LOD de terreno integrado, descarte mediante octrees, física Havok (Wasm) y compatibilidad madura con WebGPU. Utilizar herramientas del ecosistema de Three.js cuando Babylon no disponga de equivalentes (por ejemplo, BVH de mallas para consultas espaciales). Envolverlo todo en una capa personalizada de streaming del mundo.

Arquitectura de streaming del mundo

Esta es la parte difícil. Una pestaña del navegador dispone aproximadamente de entre 2 y 4 GB de memoria en equipos de escritorio (por límites impuestos por el navegador), alrededor de 1 GB en dispositivos móviles y ningún acceso directo al disco. Todo llega a través de la red. Se necesita una arquitectura que mantenga en memoria el mundo visible mientras transmite contenido justo por delante de la dirección en la que se desplaza el jugador.

Cuadrícula del mundo basada en chunks

Al igual que el sistema de celdas de Skyrim, hay que dividir el mundo en una cuadrícula regular de chunks. Cada chunk es una unidad independiente que puede cargarse, renderizarse y descargarse por separado.

El tamaño de los chunks importa. Si son demasiado pequeños, se cargan y descargan constantemente, lo que genera una gran sobrecarga. Si son demasiado grandes, cada chunk tarda demasiado en descargarse. Para un mundo en el navegador con conexiones de banda ancha habituales:

• Chunks de 64x64 metros a nivel del suelo
• Cada chunk contiene: sección de mapa de altura (2-4 KB), mapa de mezcla de texturas (16-32 KB comprimido), mallas estáticas como referencias de instancias (1-50 KB de datos de instancias) y objetos colocados por los creadores como manifiesto (1-10 KB)
• Radio de carga: 5x5 chunks con detalle completo (vista de 320 m), 9x9 con LOD medio y 17x17 solo con terreno
• Objetivo: mantener los datos de detalle completo de cada chunk por debajo de 200 KB, para que un entorno de 5x5 ocupe menos de 5 MB

Canal de carga progresiva

No hay que cargar de una sola vez toda la información de un chunk. Se utiliza una cola de prioridades:

1. Primero, la geometría del terreno (solo el mapa de alturas, 2-4 KB por sector). El jugador ve el suelo en menos de 100 ms.
2. Texturas del terreno (mapas de mezcla, primero en baja resolución y luego se mejoran). El suelo tiene color en menos de 200 ms.
3. Estructuras principales (edificios, rocas grandes). Las siluetas aparecen en menos de 500 ms.
4. Objetos de detalle (vegetación, elementos pequeños, objetos de creadores). El mundo se completa en 1-2 segundos.
5. Las texturas de alta resolución se mejoran al final. Nadie nota si la textura de un edificio lejano tarda un segundo más.

Esto coincide con el funcionamiento del ojo humano. Notamos si falta el suelo o alguna estructura grande. No notamos si falta la hierba.

Gestión de memoria

La memoria del navegador es limitada y el recolector de basura es tu enemigo. Una sola pausa del GC puede hacer que pases de 60 fps a 10 fps durante un fotograma.

La reutilización de objetos es obligatoria. Preasigna conjuntos de objetos comunes (árboles, rocas, zonas de hierba) y recíclalos a medida que se cargan y descargan los sectores. Nunca crees nuevas instancias de THREE.Mesh o BABYLON.Mesh en la ruta crítica. En su lugar, intercambia las referencias de geometría y material de los objetos reutilizados.

Los atlas de texturas reducen tanto las llamadas de dibujado como la fragmentación de memoria. Empaqueta todas las texturas del terreno en unos pocos atlas grandes. Empaqueta en el servidor las texturas subidas por los creadores en atlas por sector y transmítelas como imágenes individuales.

La compresión de geometría con Draco o Meshopt reduce el tamaño de descarga entre 5 y 10 veces, y la descompresión se ejecuta en un Web Worker para no bloquear el hilo principal. En el caso específico del terreno, los mapas de alturas cuantizados (valores de 16 bits comprimidos mediante una codificación delta sencilla) ocupan menos que cualquier formato de malla de propósito general.

La transferencia de propiedad de ArrayBuffer entre los workers y el hilo principal evita las copias. Cuando un worker descomprima una malla, transfiere el búfer al hilo principal sin copiarlo mediante postMessage con objetos transferibles.

Entrega de recursos

CDN con almacenamiento en caché perimetral para los datos estáticos del mundo. Los sectores del terreno, las mallas base y los atlas de texturas que no cambien con frecuencia deben almacenarse en caché de forma agresiva (Cache-Control: max-age=31536000, immutable).

El almacenamiento direccionado por contenido implica que cada versión de un recurso recibe un hash único en su URL. Cuando un creador modifica un sector, la nueva versión recibe un hash nuevo y la anterior permanece en caché para quien todavía la esté viendo. No es necesario invalidar la caché.

Texturas KTX2 con compresión Basis Universal. Estas se descomprimen al formato de GPU que admita el dispositivo (BC7, ASTC, ETC2 o RGBA como alternativa). Una textura de terreno de 1024x1024 pasa de 4 MB sin comprimir a unos 150 KB en KTX2. En un mundo con miles de texturas únicas, esta compresión marca la diferencia entre un proyecto viable y uno que no lo es.

glTF Binary (GLB) para todos los recursos 3D. Es el JPEG del 3D. Todos los motores de navegador pueden cargarlo, es compacto y permite integrar texturas, materiales y animaciones en un solo archivo. Usa las extensiones Draco o Meshopt para comprimir las mallas. Los recursos subidos por los creadores se procesan en el servidor para convertirlos en archivos GLB optimizados antes de incorporarse al mundo.

Redes multijugador

Reunir a cientos de creadores en el mismo mundo requiere una arquitectura de red que gestione el movimiento en tiempo real, el estado persistente del mundo y las ediciones de los creadores sin colapsar.

Arquitectura del servidor

Servidor autoritativo para el estado del mundo. No se puede confiar en el navegador. Todas las acciones relevantes (colocar objetos, modificar el terreno o desplazarse entre sectores) se validan en el servidor. El cliente realiza predicciones locales y se reconcilia con el estado del servidor.

La fragmentación espacial divide el mundo entre varias instancias de servidor. Cada fragmento controla una región rectangular de la cuadrícula del mundo. A medida que cambia la densidad de jugadores, los fragmentos pueden dividirse o fusionarse. Así es como EVE Online gestiona a miles de jugadores en un mismo universo, y el mismo principio funciona a menor escala.

En un mundo de creadores donde la mayoría de las interacciones son locales (construyes en tu zona y tus vecinos pueden verlo), la fragmentación espacial funciona de forma natural. Un jugador situado en el límite de un fragmento ve el contenido de ambos, lo cual requiere consultas de visibilidad entre fragmentos, pero este es un problema ya resuelto.

Opciones tecnológicas para el servidor:

Tecnología	Ventajas	Caso de uso
Cloudflare Durable Objects	Despliegue perimetral, escalado automático, persistencia integrada y compatibilidad con WebSocket	Estado de los fragmentos del mundo, autoridad por sector
Hathora / Rivet	Alojamiento administrado de servidores de juego, protección contra DDoS y despliegue global	Instancias de servidores de juego dedicados
Colyseus	Framework de código abierto para servidores de juegos en Node.js, sincronización de estado basada en esquemas	Multijugador basado en salas con sincronización diferencial del estado
PartyKit	Despliegue perimetral, WebSocket + WebRTC, basado en Cloudflare Workers	Colaboración en tiempo real, multijugador ligero
Custom Rust/Go	Máximo control, mejor rendimiento por instancia	Fragmentos de alta densidad que requieran físicas de baja latencia

Nuestro contexto (infraestructura de Cloudflare): Durable Objects encaja de forma natural. Cada sector del mundo se convierte en un Durable Object que mantiene el estado autoritativo del contenido de ese sector. Los jugadores se conectan mediante WebSocket al Durable Object responsable de su sector actual. Cuando se desplazan a un sector adyacente, se conectan al DO de ese sector. Durable Objects guarda automáticamente el estado en disco, por lo que los datos del mundo sobreviven a los reinicios.

Comunicación cliente-servidor

WebSocket para mensajes fiables y ordenados (chat, ediciones del mundo, inventario y estado del juego). Una conexión por cada fragmento activo que el jugador pueda ver (normalmente entre 1 y 4 conexiones).

WebRTC DataChannel para mensajes no fiables y no ordenados (posiciones de jugadores, animaciones y efectos efímeros). WebRTC permite conexiones entre pares, pero en un mundo con muchos jugadores conviene utilizar una SFU (unidad de reenvío selectivo) para evitar N2 conexiones. Cloudflare Calls o LiveKit pueden actuar como SFU.

La sincronización del estado utiliza compresión delta. El servidor registra lo que ha visto cada cliente y solo envía los cambios. Esto es especialmente importante en un mundo de creadores, porque el estado del mundo (qué objetos existen, dónde están y qué propiedades tienen) cambia con mucha menos frecuencia que las posiciones de los jugadores. Puedes permitirte enviar actualizaciones del estado del mundo a 2-5 Hz mientras las posiciones de los jugadores se actualizan a 20-30 Hz.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

Resolución de conflictos en las ediciones de los creadores

Cuando dos creadores modifican simultáneamente la misma zona, necesitas una estrategia para resolver conflictos. Aquí es donde importa la elección del modelo de colaboración en tiempo real.

Prevalece la última escritura es la opción más sencilla. Cada objeto tiene un único propietario en un momento dado. Si estás editando un edificio, nadie más puede editarlo hasta que lo liberes. Es sencillo y no genera conflictos, pero limita la colaboración.

La transformación operacional (OT) es lo que utiliza Google Docs. Las operaciones se transforman teniendo en cuenta las operaciones concurrentes para producir un resultado coherente. Funciona bien con texto, pero se complica en las operaciones espaciales 3D. Figma utiliza una variante de este sistema para su lienzo 2D.

Los CRDT (tipos de datos replicados sin conflictos) permiten realizar ediciones concurrentes que siempre convergen en el mismo estado sin necesidad de coordinación. Para un mundo con objetos discretos (cada uno con un ID y sus propiedades), un registro en el que prevalezca la última escritura para cada propiedad, combinado con un conjunto en el que prevalezcan las adiciones para la colección de objetos, proporciona convergencia automática. Yjs y Automerge son bibliotecas CRDT para JavaScript con calidad de producción.

Nuestra recomendación: usa CRDT para el estado de los objetos del mundo (qué existe, dónde está y qué propiedades tiene) y un servidor autoritativo para la validación espacial (que no haya dos objetos en el mismo lugar y que los objetos permanezcan dentro de los límites del mundo). El CRDT gestiona la colaboración. El servidor gestiona las físicas.

Gestión de la escala: ¿cuántos jugadores?

Los MMO para navegador ya existen. Hordes.io admite más de 200 jugadores en una misma escena dentro del navegador. BrowserQuest (el experimento de Mozilla) gestionaba a cientos de jugadores con un sencillo mundo basado en casillas. La cuestión no es si los navegadores pueden gestionar el multijugador, sino qué fidelidad visual puedes mantener a medida que aumenta el número de jugadores.

Presupuesto de renderizado de jugadores: cada jugador visible necesita una malla, animaciones y, potencialmente, una apariencia personalizada por el creador. A 60 fps, dispones de 16 ms por fotograma. Un presupuesto razonable sería:

• 50 jugadores totalmente animados a corta distancia: ~2 ms de animación + deformación esquelética
• 200 jugadores a media distancia (animación simplificada y renderizado por instancias): ~1 ms
• Más de 500 jugadores como puntos o iconos en el minimapa: coste insignificante

Esto permite mostrar una población visible de unos 250 jugadores en una sola vista, más que suficiente para un mundo de creadores. Las capitales de World of Warcraft rara vez muestran más de 200 personajes a la vez.

Presupuesto de red: cada jugador que envía su posición a 20 Hz genera aproximadamente 40 bytes * 20 = 800 bytes/segundo. Con 200 jugadores visibles, son 160 KB/s de datos de posición. Si añades el estado del mundo, el chat y las acciones de los creadores, obtienes entre 200 y 500 KB/s por cliente. Está dentro de las capacidades de la banda ancha, aunque merece la pena comprimirlo.

Sistema de terreno

El terreno es la base de cualquier mundo abierto. También es donde más se notan las limitaciones del navegador, porque debe estar en todas partes y permanecer siempre visible.

Terreno basado en mapas de alturas

Al igual que Skyrim, utiliza un mapa de alturas. Una cuadrícula 2D de valores de altura genera terreno 3D mediante un sombreador de vértices. Es muchísimo más compacto que un terreno formado por mallas arbitrarias.

Un mapa de alturas de 4096x4096 con una precisión de 16 bits ocupa 32 MB sin comprimir. Pero nunca se carga entero de una vez. Cada sector de 64 m utiliza una sección de 65x65 del mapa de alturas (unos 8,4 KB a 16 bits). Si la comprimes con codificación delta y zlib, ocupa menos de 2 KB por sector.

La mezcla de texturas pinta varios materiales de terreno (hierba, roca, tierra y arena) mediante un mapa de mezcla. Cada sector tiene un mapa de mezcla RGBA de 4 canales, donde cada canal controla el peso de mezcla de un material. Con 4 texturas por mapa de mezcla y la posibilidad de variar estos mapas en cada sector, se consigue diversidad visual en todo el mundo.

Los renderizadores de terreno modernos utilizan texturizado virtual (también llamado megatextura, procedente de la tecnología de id Software para Rage). En lugar de mezclar las texturas durante la ejecución, se prerenderiza la textura combinada del terreno a alta resolución y se transmiten sus mosaicos a medida que se mueve la cámara. Esto intercambia espacio de almacenamiento por rendimiento durante la ejecución. Los sombreadores de cómputo de WebGPU pueden gestionar la retroalimentación y las tablas de páginas necesarias para el texturizado virtual.

Clipmap o geomapeado por niveles

Para renderizar terrenos grandes en un navegador, funcionan bien CDLOD (LOD de C. Dick) o el geomapeado por niveles. El terreno se renderiza como un conjunto de anillos concéntricos alrededor de la cámara, cada uno con la mitad de resolución que el anterior. Cerca de la cámara se ve el terreno a resolución completa. A lo lejos se muestra una versión menos detallada. Las transiciones son fluidas porque la geometría se transforma gradualmente entre niveles.

Esta técnica es eficiente para la GPU (una llamada de dibujado por anillo), permite gestionar terreno infinito con una cantidad constante de memoria y funciona en WebGL 2. Es lo que utilizan Flight Simulator y la mayoría de los juegos modernos de mundo abierto en algún nivel.

Terreno modificado por los creadores

Si los creadores pueden esculpir el terreno, necesitas una forma de almacenar y transmitir las modificaciones sobre el mapa de alturas base. Hay dos enfoques:

Los mapas de alturas delta almacenan la diferencia entre el terreno base y el terreno modificado. La mayor parte del mundo no está modificada (los deltas son cero), por lo que se comprime extremadamente bien. Al cargar un sector, aplica el delta sobre la base.

Las capas de vóxeles permiten realizar modificaciones más drásticas (cuevas, salientes y arcos). Un mapa de alturas no puede representar un terreno donde un punto tenga dos alturas. Una cuadrícula de vóxeles dispersa, almacenada únicamente en los sectores modificados, permite hacerlo. Marching Cubes o el contorneado dual generan la malla. Es más costoso, pero permite editar el terreno al estilo de Minecraft.

Generación de mundos con IA

Aquí es donde las capacidades actuales de IA generativa de Cinevva se convierten en un multiplicador de fuerza. En lugar de crear manualmente cada roca y cada árbol, los creadores pueden indicar a la IA cómo poblar el mundo.

Generación de terreno con campos neuronales

Las investigaciones recientes sobre generación neuronal de terrenos (GET3D de NVIDIA, el modo de red neuronal de Terragen y artículos como "Terrain Generation Using Procedural Models") demuestran que los modelos entrenados pueden generar terrenos verosímiles a partir de instrucciones de texto o bocetos. Un creador podría dibujar una costa aproximada y decir «colinas boscosas que llegan hasta una costa rocosa» para obtener un mapa de alturas con la erosión, las máscaras de vegetación y las asignaciones de materiales apropiadas.

Para entregarlo al navegador, la generación se ejecutaría en el servidor y se transmitiría el resultado. El modelo generativo no necesita ejecutarse en el navegador. Produce mapas de alturas y mapas de mezcla que el navegador puede renderizar mediante el flujo de procesamiento estándar del terreno.

Generación de recursos 3D

Modelos como Hunyuan3D, Meshy, Tripo y Rodin pueden generar mallas 3D a partir de texto o imágenes. El flujo de trabajo para un mundo de creadores sería:

1. El creador describe o dibuja lo que quiere («un arco de piedra cubierto de musgo» o «una farola futurista»)
2. El servidor ejecuta el modelo generativo y produce una malla de alta densidad
3. El servidor la procesa automáticamente: reduce el número de polígonos a una cantidad adecuada para la web, genera los LOD, hornea las texturas en un atlas y exporta el resultado como GLB con compresión Draco
4. El recurso aparece en el inventario del creador, listo para colocarlo en el mundo

Este flujo ya existe por partes en Cinevva. Lo que falta es el paso de LOD/optimización y el sistema de colocación en el mundo.

Población procedural

Incluso con recursos generados mediante IA, colocar manualmente cada árbol de un bosque resulta tedioso. Las reglas de distribución procedural permiten a los creadores definir zonas («esta área es un bosque denso», «esta ladera es un pedregal») para que el sistema las pueble automáticamente.

Los sombreadores de cómputo de la GPU pueden ejecutar la distribución en el navegador. A partir de un mapa de densidad y un conjunto de reglas (separación mínima, restricciones de pendiente e intervalo de alturas), una pasada de cómputo genera las posiciones de las instancias de un sector completo en menos de 1 ms. Al modificar el mapa de densidad, la vegetación se regenera al instante.

Sistema de Entidades y Componentes (ECS)

Un mundo abierto con miles de objetos necesita un sistema eficiente de gestión de entidades. El patrón ECS (popular en los motores de juegos desde DOTS de Unity y Bevy) se adapta bien a JavaScript.

bitECS es un ECS de alto rendimiento para JavaScript que utiliza arrays tipados y operaciones bit a bit. Las entidades son simples enteros. Los componentes son arrays tipados contiguos (uno por cada tipo de componente). Los sistemas recorren los arrays secuencialmente, lo que favorece el uso de la caché incluso en JavaScript.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

En un mundo abierto, el ECS se encarga de todo: personajes de jugadores, objetos colocados, PNJ, partículas, activadores y elementos decorativos del mundo. Cuando se descarga un chunk, sus entidades se eliminan del ECS. Cuando se carga un chunk, se añaden las entidades. Al ECS no le importa la organización espacial. Simplemente procesa componentes.

Física

La física en el navegador ha mejorado sorprendentemente gracias a WebAssembly.

Rapier (Rust -> Wasm)

Rapier es un motor de física escrito en Rust que se compila a WebAssembly. Gestiona cuerpos rígidos, colisionadores, articulaciones, controladores de personajes y trazado de rayos. Su rendimiento se encuentra dentro de un factor de 2-3 respecto a Bullet/PhysX nativos para cargas de trabajo habituales en juegos.

En un mundo abierto, Rapier se encarga de:

• El controlador del personaje del jugador (caminar sobre el terreno, subir escalones, deslizarse por pendientes)
• Las colisiones entre objetos (objetos colocados, proyectiles)
• El trazado de rayos para las interacciones del jugador (hacer clic en un objeto para seleccionarlo)
• Los volúmenes activadores (entrar en una zona y activar un evento)

Rapier se ejecuta en un Web Worker, por lo que la simulación física no bloquea el renderizado. En cada fotograma, envías posiciones al renderizador y recibes a cambio los eventos de entrada.

Havok para la web (mediante Babylon.js)

Si eliges Babylon.js, el motor de física Havok viene integrado como módulo Wasm. Havok es el motor de física que utilizan muchos juegos AAA (Half-Life 2, Skyrim, Breath of the Wild). La compilación Wasm tiene calidad de producción y está optimizada para el grafo de escena de Babylon.

Colisiones del terreno

Los motores de física necesitan geometría de colisión para el terreno. Generar una malla triangular a resolución completa para todo el terreno visible sería costoso. En su lugar, genera campos de altura de colisión solo para los chunks cercanos al jugador (los 3x3 o 5x5 chunks más próximos) y utiliza colisiones simplificadas para todo lo demás. El colisionador de campos de altura de Rapier está diseñado precisamente para este caso de uso.

Audio

El sonido transforma un espacio 3D, de una demostración visual, en un lugar. La API Web Audio proporciona todo lo necesario para el audio espacial en un navegador.

El audio espacial con HRTF (función de transferencia relacionada con la cabeza) sitúa los sonidos en el espacio 3D. Una cascada a tu izquierda suena como si estuviera a tu izquierda. Al acercarte, suena más fuerte. Si caminas detrás de un edificio, se amortigua (con procesamiento adicional).

Las zonas ambientales funcionan como la mezcla de texturas aplicada al audio. Define regiones (bosque, cueva, costa, ciudad) y realiza fundidos cruzados entre paisajes sonoros ambientales a medida que el jugador se desplaza entre ellas. Así consigue Skyrim que los bosques parezcan vivos. Superpón viento, pájaros, hojas que crujen y animales lejanos. Nada de esto es complejo. Todo es espacial.

El rendimiento de Web Audio es suficiente para decenas de fuentes espaciales simultáneas. El cuello de botella suele ser el tamaño de los recursos, no el procesamiento. Utiliza Opus o AAC para el audio comprimido, transmite las pistas ambientales largas y precarga los efectos de sonido cortos (pasos, interacciones).

Agua, clima y atmósfera

Todo mundo abierto memorable tiene agua y clima. Estos sistemas definen el ambiente y hacen que el mundo parezca vivo. Además, son sorprendentemente viables en un navegador.

Renderizado del agua

El agua en 3D para navegadores tiene tres niveles de complejidad, y puedes publicar primero el más sencillo y mejorarlo más adelante.

Nivel 1: plano reflectante. Una malla plana a la altura del agua con un material reflectante/refractante. Renderiza la escena invertida en una textura (reflexión planar), mézclala con un tono azul y añade mapas de normales en movimiento para simular las olas. Esto es lo que hace el shader de agua básico de Skyrim. En Three.js, el ejemplo Water del repositorio oficial lo implementa. En Babylon.js, WaterMaterial lo ofrece de serie. Coste: una pasada de renderizado adicional para los reflejos (media resolución es suficiente), además del dibujado de la superficie del agua. En una GPU de gama media, esto añade 2-3 ms por fotograma.

Nivel 2: reflejos en espacio de pantalla + efectos basados en profundidad. En lugar de realizar una pasada de renderizado independiente para los reflejos, muestrea el búfer de fotograma existente (SSR). Añade absorción del color basada en la profundidad (el agua es más oscura donde tiene mayor profundidad), espuma en las orillas mediante comparación de profundidad y cáusticas proyectadas sobre el terreno subacuático. Esto es lo que utiliza The Witcher 3. SSR está disponible tanto en la pila de posprocesamiento de Three.js como en la canalización de renderizado de Babylon.js. Coste: 1-2 ms para SSR y un coste insignificante para los efectos de profundidad.

Nivel 3: simulación oceánica mediante FFT. Para mar abierto, utiliza una transformada rápida de Fourier para simular espectros de olas en la GPU. El artículo de Jerry Tessendorf «Simulating Ocean Water» (2001) es la base que utilizan todos los motores de juegos importantes. La FFT se ejecuta como un shader de cómputo en WebGPU y genera un mapa de desplazamiento y otro de normales en cada fotograma. El océano resultante parece extraordinariamente convincente. Esto es lo que utilizan Sea of Thieves, Assassin's Creed Black Flag y Uncharted 4. En WebGPU, una simulación oceánica FFT de 256x256 se ejecuta en menos de 1 ms en GPU de escritorio.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

Para un mundo de creadores, empieza con el nivel 1 (plano reflectante) y pasa al nivel 2 cuando el renderizador madure. El nivel 3 solo es necesario si el mundo tiene mar abierto.

Sistemas meteorológicos

El clima de Skyrim y BotW se controla mediante una máquina de estados con transiciones. Despejado > Nublado > Lluvia > Tormenta > Despejado. Cada estado modifica varios sistemas al mismo tiempo: cielo, densidad de la niebla, color de la luz ambiental, efectos de partículas (lluvia/nieve), audio (viento, lluvia) y propiedades de la jugabilidad (en BotW, las superficies mojadas son resbaladizas).

En un mundo para navegadores, el sistema meteorológico tiene tres capas:

Renderizado del cielo. Un shader de cielo procedimental es más barato y flexible que las texturas de cielo. Los modelos de cielo Preetham o Hosek-Wilkie calculan colores físicamente plausibles únicamente a partir de la posición del sol. Añade una capa de nubes utilizando ruido 3D desplazado a través de un plano. Babylon.js incluye un material de cielo procedimental. Three.js tiene el ejemplo Sky. Ambos producen resultados convincentes con un coste insignificante para la GPU (se trata de un único cuadrilátero a pantalla completa).

Efectos de partículas. La lluvia es un sistema de partículas con miles de cuadriláteros finos que caen desde arriba. La nieve es similar, pero sus trayectorias son más lentas y erráticas. La niebla es una pasada de posprocesamiento que mezcla la escena con un color de niebla según la profundidad. Todos ellos son efectos estándar de WebGL. El coste depende del número de partículas: 10 000 partículas de lluvia añaden aproximadamente 0,5 ms por fotograma.

Respuesta del entorno. Las superficies mojadas aumentan la reflexión especular. La acumulación de nieve añade blanco a las superficies orientadas hacia arriba. Aparecen charcos en las zonas cóncavas del terreno. Son trucos de shaders, no cambios de geometría. Un uniforme de «humedad» modifica la rugosidad del material. Un uniforme de «cobertura de nieve» mezcla blanco en las superficies cuyas normales apuntan hacia arriba. GTA V y The Witcher 3 utilizan exactamente este enfoque.

Clima sincronizado. En un mundo multijugador, el clima debe ser coherente para todos los clientes. El método más sencillo consiste en que el servidor transmita un estado meteorológico (incluido el progreso de la transición) a 1 Hz. Los clientes interpolan localmente. Como el clima cambia lentamente (una transición de despejado a lluvia tarda entre 30 y 60 segundos), incluso una actualización retrasada se ve fluida.

Perspectiva atmosférica

Esta es la técnica visual más eficaz para hacer que un mundo parezca grande, y su coste es casi nulo. Los objetos lejanos se ven más difusos, azulados y con menos contraste debido a la dispersión de la luz en la atmósfera. Todos los mundos abiertos la utilizan.

En un shader de fragmentos, mezcla los píxeles lejanos con el color de la atmósfera según la profundidad:

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW lleva esto más lejos con una niebla pictórica que se transforma en una distancia de estilo acuarela. El color de la niebla cambia según la hora del día y el clima. Este único efecto de shader aporta más sensación de escala que cualquier cantidad de detalle en el terreno.

Para un mundo de navegador con una dirección artística estilizada, la perspectiva atmosférica es el primer efecto visual que conviene implementar. Oculta las transiciones de LOD (los objetos lejanos con menos detalle se ven bien a través de la bruma), reduce la aparición repentina visible del contenido transmitido y hace que las capturas de pantalla se vean bien incluso antes de que el mundo esté completamente poblado.

Sistemas de avatares

Los jugadores necesitan cuerpos. En un mundo de creadores, el avatar es la principal forma de expresión personal, junto con aquello que construyes. El sistema debe ser lo bastante flexible para permitir la personalización y, al mismo tiempo, mantener unos costes de renderizado suficientemente bajos para mostrar más de 200 jugadores.

Arquitectura de los avatares

Malla base + capas de personalización. Comienza con una malla base humanoide compartida (entre 1500 y 3000 triángulos para el cuerpo). La personalización se realiza mediante:

• Variaciones de color/textura (tono de piel, color de pelo) mediante cambios de uniformes. Sin geometría adicional.
• Partes de malla intercambiables (peinados, ropa, accesorios) que sustituyen secciones de la malla base. Cada parte es una pequeña malla independiente (entre 200 y 500 triángulos).
• Variaciones de las propiedades de los materiales (armadura metálica frente a túnica de tela) mediante cambios en los parámetros de los materiales.

Así gestionan los avatares Roblox, Fortnite y VRChat. El coste base se mantiene constante independientemente de la personalización.

Ready Player Me y Avaturn ofrecen creación de avatares en el navegador y generan modelos glTF compatibles con cualquier motor 3D. Gestionan el escaneo facial a partir de fotografías, las proporciones corporales y la ropa. Los modelos resultantes están optimizados para el renderizado en tiempo real (normalmente entre 10 000 y 20 000 triángulos, reducibles a entre 3000 y 5000 para el renderizado a distancia).

Animación esquelética en el navegador

Todos los jugadores visibles necesitan animaciones: espera, caminar, correr, saltar y gestos. La animación esquelética deforma una malla mediante un conjunto de transformaciones de huesos en cada fotograma.

El skinning en la GPU es imprescindible para el rendimiento. Tanto Three.js como Babylon.js realizan el skinning en la GPU de forma predeterminada. Las matrices de huesos se cargan como un búfer de uniformes o una textura, y el shader de vértices aplica las transformaciones de los huesos. El coste para la CPU consiste en calcular las transformaciones de los huesos a partir del clip de animación. Para un esqueleto de 60 huesos a 30 fps, esto supone aproximadamente 0,01 ms por personaje. Para 200 personajes: 2 ms en total. Aceptable.

La mezcla de animaciones combina varias animaciones (caminar + saludar, espera + mirar alrededor) mediante pesos de mezcla. Tanto Three.js (AnimationMixer) como Babylon.js (AnimationGroup) son compatibles con esta función. La mezcla se realiza en la CPU (interpolando las transformaciones de los huesos) antes de enviar el resultado combinado a la GPU.

La animación instanciada es la clave para renderizar muchos personajes de forma eficiente. En lugar de dibujar cada personaje como una malla independiente, hornea los fotogramas de animación en una textura (textura de animación de vértices, o VAT). Cada fila de la textura almacena las transformaciones de los huesos para un fotograma. Un shader de cómputo o de vértices lee la fila correcta según el tiempo de animación del personaje. Esto permite renderizar cientos de personajes con una única llamada de dibujado instanciada. The Witcher 3 y Assassin's Creed utilizan esta técnica para renderizar multitudes.

En WebGPU, los personajes animados mediante instancias se ven así:

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

Para los jugadores lejanos (a más de 50 metros), cambia a impostores de billboard: un cuadrilátero plano que muestra un sprite prerenderizado del personaje desde el ángulo de visión actual. Es el mismo truco que utiliza Skyrim para los árboles lejanos, aplicado a los personajes. La transición es imperceptible a distancia.

Cinemática inversa para las interacciones

Cuando un personaje recoge un objeto, intenta alcanzar el tirador de una puerta o señala algo, la IK procedimental hace que la acción parezca natural. FABRIK (cinemática inversa de alcance hacia delante y hacia atrás) es un solucionador de IK sencillo y rápido que funciona bien en tiempo real. Tanto Three.js (mediante CCDIKSolver) como Babylon.js (mediante BoneIKController) incluyen compatibilidad integrada con IK.

En un mundo de creadores, la IK permite que los personajes interactúen con naturalidad con los objetos colocados: sentarse en sillas colocadas por los creadores, apoyarse en barandillas o recoger objetos. Las interacciones no necesitan una animación específica para cada objeto. El sistema de IK adapta la postura del personaje a la posición del objeto.

Redes avanzadas

La arquitectura básica (WebSocket + WebRTC) se explicó anteriormente. A continuación se ofrece información más detallada sobre protocolos, compresión y nuevas opciones de transporte.

Protocolos de mensajes binarios

JSON sobre WebSocket desperdicia 10 veces más ancho de banda que la codificación binaria. En un mundo multijugador en tiempo real, todos los mensajes deben ser binarios. FlatBuffers (de Google) es la opción más adecuada para las redes de juegos. A diferencia de Protocol Buffers, FlatBuffers proporciona acceso sin copias a los datos serializados. No se decodifica el mensaje en objetos de JavaScript. Los campos se leen directamente del búfer. Esto elimina las asignaciones y la presión sobre el recolector de basura que Protocol Buffers generaría en una ruta crítica. FlatBuffers dispone de un generador de código para JavaScript/TypeScript.

Una actualización de la posición de un jugador en FlatBuffers:

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

Para 200 jugadores a 20 Hz, la diferencia es 200 * 17 * 20 = 68 KB/s (binario) frente a 200 * 80 * 20 = 320 KB/s (JSON). El formato binario es 4,7 veces más pequeño y evita las asignaciones de JSON.parse en el bucle crítico.

MessagePack es más sencillo que FlatBuffers (sin esquema ni generación de código), pero sigue siendo entre un 30 y un 50 % más pequeño que JSON. Es un buen punto intermedio si quieres datos binarios sin tener que gestionar esquemas.

Cuantización de posiciones y compresión delta

Las posiciones de los jugadores no necesitan la precisión de un número de coma flotante de 32 bits. Si tu mundo mide 4 km x 4 km, un entero sin signo de 16 bits ofrece una precisión de 6 cm (4000 m / 65536). En la mayoría de los juegos, es indistinguible de la precisión completa. Esto reduce a la mitad el tamaño de los datos de posición.

La compresión delta solo envía la diferencia respecto al último estado confirmado. Si un jugador se ha desplazado 0,5 metros desde la última actualización, el delta es un número pequeño que se comprime bien. Combinada con una codificación de longitud variable (los deltas más pequeños usan menos bytes), las actualizaciones de posición comprimidas mediante delta suelen ocupar entre 3 y 6 bytes en lugar de 12.

La navegación por estima reduce la frecuencia de actualización. En lugar de enviar la posición a 20 Hz, se envían la posición y la velocidad. El cliente extrapola la posición entre actualizaciones. Solo se envía una corrección cuando la posición real se desvía de la posición prevista por encima de un umbral. Esto puede reducir entre un 60 y un 80 % el ancho de banda de las actualizaciones de posición para los jugadores que se desplazan en línea recta, que es la mayoría del movimiento.

RuneScape utiliza una versión extrema de este sistema: el movimiento de los jugadores se basa en casillas, por lo que una orden de movimiento es simplemente una casilla de destino. El cliente anima localmente la trayectoria. En un mundo 3D continuo se usaría una navegación por estima suave, pero el principio es el mismo.

WebTransport

WebTransport es un protocolo más reciente que podría sustituir tanto a WebSocket como a WebRTC DataChannel para las redes de juegos. Funciona sobre HTTP/3 (QUIC) y ofrece:

• Flujos fiables y ordenados (como WebSocket, pero multiplexados, de modo que un bloqueo en un flujo no detenga los demás)
• Datagramas no fiables (como UDP, para actualizaciones de posición que quedan obsoletas de inmediato si se retrasan)
• Flujos multiplexados (flujos separados para el chat, el estado del mundo y las posiciones, sin bloqueo de cabecera de línea)

Esto es exactamente lo que necesitan las redes de juegos. WebSocket ofrece una comunicación fiable y ordenada, pero el bloqueo de cabecera de línea perjudica la latencia de las actualizaciones de posición. WebRTC DataChannel permite comunicación no fiable, pero su configuración es compleja y requiere ICE/STUN. WebTransport ofrece ambas cosas mediante una sola conexión.

Compatibilidad con navegadores: Chrome, Edge y Firefox ofrecen WebTransport desde hace tiempo, y Safari 26.4 lo incorporó en marzo de 2026. Ese cambio llevó a WebTransport al estado Baseline, lo que significa que ahora funciona en todos los navegadores principales, incluido iOS, donde todos los navegadores utilizan WebKit. Sigue mereciendo la pena mantener WebSocket como alternativa para las versiones anteriores de Safari, pero WebTransport ya puede utilizarse ampliamente.

Cloudflare admite WebTransport mediante Workers, lo que encaja con nuestra infraestructura.

Gestión de relevancia a gran escala

El reto de red con más de 200 jugadores no es el ancho de banda por jugador. Es el problema cuadrático: si cada jugador envía actualizaciones a todos los demás, 200 jugadores implican 200 * 199 = 39.800 mensajes de actualización por tick. El servidor necesita filtrarlos.

La gestión del área de interés (AOI) significa que cada jugador solo recibe actualizaciones sobre las entidades que se encuentran dentro de su rango de visión. La implementación utiliza la misma cuadrícula espacial que el sistema de chunks: cuando la posición de un jugador corresponde al chunk (3, 7), recibe actualizaciones de los chunks (2-4, 6-8), un vecindario de 3x3. Las entidades situadas fuera de este rango no se envían.

Las actualizaciones basadas en prioridades dentro del AOI destinan más ancho de banda a las entidades importantes. Un jugador que corre hacia ti recibe actualizaciones a 20 Hz. Un jugador inmóvil a 200 metros recibe actualizaciones a 2 Hz. Un PNJ que no hace nada recibe actualizaciones a 0,5 Hz. El servidor mantiene una cola de prioridad por cliente y asigna el ancho de banda según la relevancia de cada entidad (distancia, velocidad y posibilidad de interacción).

Inactividad. Las entidades cuyo estado no ha cambiado durante N segundos pasan a estar inactivas y dejan de generar tráfico de red por completo. El cliente conserva el último estado conocido hasta que recibe un evento de reactivación. En un mundo creado por usuarios, donde la mayoría de los objetos colocados son estáticos, la inactividad elimina la mayor parte del tráfico de red potencial.

La frecuencia de ticks variable de Slither.io (5 Hz para elementos lejanos frente a 30 Hz para los cercanos) es una versión simplificada de este enfoque. La «dilatación temporal» de EVE Online es la versión extrema: cuando hay demasiados jugadores en una misma zona, el servidor reduce la frecuencia de ticks del juego para mantener la coherencia. Para nuestro caso de uso, un AOI basado en prioridades y con inactividad ofrece el equilibrio adecuado.

Gaussian Splatting y nuevas tecnologías de renderizado

El renderizado tradicional de mallas (triángulos + texturas) ya no es la única opción para crear 3D en el navegador. Varias técnicas más recientes están alcanzando la viabilidad necesaria para usarse en producción.

Gaussian Splatting 3D

Gaussian Splatting 3D (SIGGRAPH 2023): reconstrucción fotorrealista de escenas a partir de fotografías, renderizada en tiempo real en el navegador. Los creadores podrían escanear objetos del mundo real con un teléfono y colocarlos directamente en el mundo.

Gaussian Splatting 3D (3DGS) reconstruye escenas 3D a partir de fotografías representándolas como millones de gaussianas 3D coloreadas (elipsoides orientados y coloreados). El renderizador ordena y rasteriza estos splats en lugar de triángulos.

Por qué es importante para un mundo creado por usuarios:

• La captura fotogramétrica se vuelve trivial. Un creador toma con su teléfono 50 fotos de un objeto o lugar del mundo real. El procesamiento en el servidor (mediante herramientas como Nerfstudio o gsplat) produce en minutos una escena de Gaussian Splatting. Esa escena se carga en el navegador y ofrece un aspecto fotorrealista desde cualquier ángulo.
• El renderizado en el navegador está resuelto. Varias implementaciones de código abierto renderizan Gaussian Splats en WebGL y WebGPU. PlayCanvas incorpora renderizado de splats. Luma AI dispone de un visor compatible con Three.js. gsplat.js es una biblioteca independiente. El rendimiento es bueno: entre 1 y 3 millones de splats se renderizan a 30-60 fps en GPU de escritorio.
• El formato de datos es compacto. Una escena de Gaussian Splatting de una habitación puede ocupar entre 10 y 30 MB comprimida. Los objetos individuales ocupan entre 1 y 5 MB. Es comparable a los recursos de malla con texturas.

La contrapartida es que las escenas de splats son estáticas. No se pueden animar ni modificar fácilmente. Funcionan bien como elementos decorativos del entorno —un árbol fotorrealista, una escultura real capturada o la fachada escaneada de un edificio—, pero no para objetos interactivos del juego. El enfoque híbrido consiste en utilizar splats para los detalles ambientales y mallas tradicionales para los objetos interactivos.

Para un mundo creado por usuarios: permite que los creadores capturen objetos reales mediante fotografías tomadas con el teléfono, los procesen en el servidor para convertirlos en Gaussian Splats y los coloquen en el mundo. Esto salva la distancia entre los recursos generados por IA y los objetos del mundo real. Un creador podría escanear sus propias obras de arte, muebles o elementos arquitectónicos y colocarlos directamente en el mundo compartido.

De campos de radiancia neuronal (NeRF) a mallas

Los NeRF representan escenas como redes neuronales que generan color y densidad para cualquier punto 3D. Producen una calidad visual extraordinaria a partir de fotografías, pero su renderizado es costoso, ya que requiere una pasada completa de inferencia de la red neuronal por píxel y fotograma.

El enfoque práctico para navegadores consiste en entrenar un NeRF a partir de fotografías y extraer después una malla mediante marching cubes sobre el campo de densidad. El resultado es una malla tradicional de triángulos con texturas precalculadas que cualquier motor para navegadores puede renderizar. Herramientas como Instant-NGP, Nerfstudio y Neuralangelo automatizan este flujo de trabajo. La calidad no es tan alta como al renderizar directamente el NeRF, pero es compatible con los procesos de renderizado estándar.

Esta es otra forma de que los creadores incorporen objetos del mundo real al mundo del navegador sin tener conocimientos de modelado.

Mesh shaders y renderizado al estilo Nanite

El sistema Nanite de UE5 renderiza miles de millones de triángulos mediante mesh shaders, renderizado controlado por la GPU y geometría virtual, transmitiendo triángulos por clúster según su cobertura en pantalla. WebGPU todavía no admite mesh shaders, pero el principio subyacente —renderizado controlado por la GPU con descarte y selección de LOD basados en cómputo— sí puede implementarse.

Un shader de cómputo de WebGPU puede:

1. Leer todos los volúmenes delimitadores de los clústeres de mallas (grupos de unos 64 triángulos)
2. Comprobar cada clúster respecto al frustum de visión y al búfer de oclusión
3. Seleccionar el nivel de LOD adecuado según su tamaño en el espacio de pantalla
4. Escribir los clústeres visibles en un búfer de dibujo indirecto
5. Renderizarlo todo con una sola llamada de dibujo indirecto

Este enfoque de «geometría virtual» gestiona millones de triángulos con un coste constante para la CPU: esta envía una sola llamada de dibujo independientemente de la complejidad de la escena. Así es como el renderizado en navegadores acabará gestionando grandes mundos abiertos. La implementación es compleja, pero los componentes necesarios ya existen en WebGPU.

Técnicas de shaders para mundos abiertos estilizados

Una dirección artística estilizada necesita técnicas de shaders específicas. Estas son las que proporcionan el mayor impacto visual por ciclo de GPU.

Animación de vegetación por viento

Los árboles y la hierba que se mecen con el viento hacen que un mundo parezca vivo. La técnica es sencilla: en el shader de vértices, se desplazan las posiciones de los vértices mediante una combinación de ondas sinusoidales determinadas por la posición en el mundo y el tiempo.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

El heightFactor garantiza que la base del árbol permanezca anclada mientras la parte superior es la que más se balancea. El uso de la posición en el mundo dentro de la función sinusoidal hace que los árboles adyacentes se muevan con fases ligeramente distintas, lo que crea un efecto ondulante natural a través del bosque. BotW, Skyrim y todos los mundos abiertos con vegetación utilizan esta técnica.

Para la hierba se aplica el mismo principio, pero con una frecuencia mayor y una longitud de onda menor. Las briznas de hierba instanciadas en la GPU —miles de cuadriláteros finos— con desfases aleatorios por instancia producen praderas convincentes con un coste mínimo. Los shaders de cómputo de WebGPU pueden generar las posiciones y orientaciones de las briznas a partir de un mapa de densidad, incorporando el viento a las transformaciones de cada instancia en cada fotograma.

Sombreado toon/cel shading

Si la dirección artística es estilizada —y los indicios sugieren que debería serlo—, el cel shading es la técnica fundamental. La idea consiste en cuantizar la iluminación en pasos discretos en lugar de usar gradientes suaves.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

Esto produce el clásico aspecto de dos o tres tonos. Añade una pasada de contorno —renderizando las caras traseras ligeramente expandidas o utilizando un posproceso de detección de bordes en el espacio de pantalla— para obtener un efecto de cómic.

El sombreado de BotW es más matizado que el cel shading puro. Utiliza un gradiente suave con un ligero salto en el límite de las sombras, además de un cambio de colores cálidos a fríos: las sombras tienen un tinte azulado y las zonas iluminadas son cálidas. Este enfoque híbrido parece más natural que el sombreado toon estricto sin dejar de percibirse como estilizado. Puede conseguirse con un shader personalizado en cualquier motor 3D para navegadores.

Shader de agua estilizada

El agua de un mundo estilizado no necesita una simulación realista de las olas. Una combinación de mapas de normales con desplazamiento, detección de espuma en los bordes y color basado en la profundidad produce resultados visualmente coherentes con una dirección artística al estilo de BotW.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

Esto proporciona una coloración basada en la profundidad —el agua poco profunda es más clara—, espuma animada con ruido en la orilla, y todo se ejecuta en una sola pasada del shader de fragmentos.

Oclusión ambiental en espacio de pantalla (SSAO)

SSAO oscurece las esquinas, las grietas y las zonas donde se encuentran las superficies. Añade profundidad y hace que los elementos parezcan asentados en la escena sin necesidad de una costosa iluminación global. Tanto Three.js como Babylon.js incluyen implementaciones de SSAO.

En un mundo estilizado, SSAO es incluso más importante que en un renderizado realista, porque el sombreado plano no muestra sombras de contacto de manera natural. Una pasada ligera de SSAO —a media resolución es suficiente— añade las señales de profundidad que faltan. Coste: entre 1 y 2 ms en GPU de escritorio.

Generación de mundos en profundidad

El artículo base trató el terreno procedimental a grandes rasgos. Veamos ahora los detalles algorítmicos.

Funciones de ruido para terrenos

Todo terreno procedimental comienza con ruido. La función de ruido produce valores pseudoaleatorios que varían suavemente en el espacio. La superposición de varias octavas —frecuencias— produce resultados de aspecto natural.

El ruido Perlin es el clásico. El ruido simplex es más rápido y presenta menos artefactos direccionales. OpenSimplex 2 es la variante moderna con buen rendimiento en JavaScript. Para los shaders de cómputo de WebGPU, implementar ruido simplex en WGSL es sencillo: son unas 50 líneas de operaciones matemáticas.

El movimiento browniano fractal (fBm) superpone octavas de ruido:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

Con 6-8 octavas, el fBm produce terrenos con formaciones montañosas a gran escala, colinas a escala media y rugosidad a pequeña escala, de forma muy similar al terreno real. El parámetro de persistencia controla la rugosidad del terreno (0,3 produce colinas suaves y onduladas; 0,7 produce montañas escarpadas).

La deformación de dominio utiliza la salida de una función de ruido como coordenadas de entrada de otra. Esto produce terrenos que parecen erosionados y orgánicos, en lugar de uniformemente accidentados. Al aplicar 2-3 capas de deformación de dominio, el terreno empieza a parecer modelado por procesos geológicos.

Simulación de erosión hidráulica

El terreno generado con ruido sin procesar parece papel arrugado. El terreno real parece papel arrugado sobre el que ha llovido durante un millón de años. La simulación de erosión hidráulica transforma el terreno generado con ruido en algo geológicamente verosímil.

El algoritmo:

1. Deja caer una partícula de agua en una posición aleatoria del mapa de alturas
2. La partícula fluye cuesta abajo (siguiendo el gradiente del terreno)
3. En cada paso, recoge sedimentos del terreno según la velocidad y la pendiente
4. Cuando la partícula se ralentiza (terreno más llano, acumulación de agua), deposita sedimentos
5. Repite el proceso con entre 100.000 y 500.000 partículas

El resultado es un terreno con valles fluviales, abanicos aluviales, crestas de aspecto natural y pendientes suaves con transiciones coherentes. El algoritmo se ejecuta sobre un mapa de alturas de 1024x1024 en unos 2-5 segundos en JavaScript, o en menos de 100 ms mediante un shader de cómputo de WebGPU.

La implementación de Sebastian Lague (disponible en GitHub) es la referencia estándar para desarrolladores de juegos. Produce terrenos comparables a resultados esculpidos a mano. En un mundo de creadores, ejecutar la erosión sobre terrenos generados por IA durante el procesamiento del lado del servidor haría que los paisajes generados mediante procedimientos parecieran elaborados a mano.

Asignación de biomas

Los mundos reales tienen biomas: bosques, desiertos, tundra y pantanos. La asignación de biomas vincula parámetros climáticos con regiones del terreno.

El enfoque de Minecraft resulta ilustrativo: definir biomas en una cuadrícula 2D mediante los ejes de temperatura y humedad. La temperatura disminuye con la altitud y la latitud. La humedad varía según la proximidad al agua y la dirección del viento predominante. Cada celda de la cuadrícula recibe una asignación de bioma (bosque, desierto, tundra, etc.) que determina las texturas del terreno, el tipo y la densidad de la vegetación, el sonido ambiental y los patrones meteorológicos.

En un mundo de creadores, los límites de los biomas deberían poder pintarse. El sistema genera biomas predeterminados a partir de las propiedades del terreno, pero los creadores pueden reemplazar la asignación pintando zonas de bioma en sus parcelas. Este enfoque híbrido proporciona al mundo un aspecto natural de forma predeterminada, al tiempo que permite a los creadores plasmar su visión.

Colapso de la función de onda para estructuras

El colapso de la función de onda (WFC) genera estructuras (edificios, mazmorras y carreteras) a partir de un conjunto de piezas con restricciones de adyacencia. Dado un conjunto de módulos de construcción y unas reglas que determinan qué piezas pueden conectarse entre sí, WFC puede generar pueblos enteros, diseños de castillos o mapas de mazmorras.

En un mundo de creadores, WFC permite:

• Pueblos generados automáticamente para poblar el mundo con contenido inicial antes de que los creadores lo personalicen
• Construcción asistida, donde un creador coloca unas pocas piezas y WFC rellena los huecos (como Townscaper, pero con bloques de construcción 3D)
• Generación de mazmorras para experiencias interactivas que los creadores pueden configurar (establecen el tema, la dificultad y el tamaño, y WFC genera la distribución)

Oskar Stalberg (creador de Townscaper y Bad North) ha demostrado que la generación basada en WFC resulta mágica para los usuarios. Colocan unos cuantos bloques y el sistema genera estructuras estéticamente coherentes a su alrededor. Este es exactamente el principio de «herramientas sencillas, resultados ricos» que triunfa en las plataformas de creadores.

Arquitectura de moderación de contenido

En un mundo donde los creadores colocan contenido 3D arbitrario que otros pueden ver, la moderación no es opcional. Es un componente esencial de la infraestructura.

Flujo de revisión automatizada

Cada recurso que entra en el mundo pasa por un proceso de varias etapas antes de hacerse visible para otros jugadores:

1. Análisis de geometría. Se escanea la malla en busca de formas anatómicamente explícitas mediante un clasificador entrenado. Esto detecta la mayoría de los modelos 3D manifiestamente inapropiados. Varias API comerciales (Azure Content Safety y Google Cloud Vision para 3D) se encargan de ello. El clasificador se ejecuta sobre la silueta de la malla desde varios ángulos, lo que resulta poco costoso en términos de cómputo.

2. Análisis de texturas. Cada textura se procesa mediante una API estándar de moderación de contenido de imágenes (las mismas que se utilizan para las fotografías subidas). Esto detecta imágenes inapropiadas aplicadas como texturas sobre geometría que, por lo demás, es inocua.

3. Detección de texto. Si el objeto contiene texto (ya sea en una textura o como una malla de texto 3D), se ejecuta OCR y se comprueba si cumple la política de contenido. Esto detecta discursos de odio, insultos y otras infracciones basadas en texto.

4. Aprobación automatizada. Si supera todas las comprobaciones, el recurso se hace visible de inmediato. Si alguna comprobación marca el recurso, este pasa a una cola de revisión.

5. Revisión humana. Los recursos marcados los revisa un moderador. En una plataforma pequeña, puede encargarse el propio equipo. A gran escala, pueden contratarse servicios de moderación externos (los mismos que moderan contenido de redes sociales).

Moderación espacial

Más allá de los recursos individuales, la disposición espacial de los objetos puede resultar inapropiada incluso cuando cada objeto por separado es aceptable. Esto es más difícil de detectar automáticamente. El enfoque práctico:

• Denuncias de jugadores. Cualquier jugador puede denunciar una ubicación. La denuncia incluye una captura de pantalla (tomada automáticamente en las coordenadas denunciadas) y la cuenta del jugador que la presenta. Las denuncias activan una revisión humana.
• Mapas de calor. Se realiza un seguimiento de las zonas que generan denuncias. Si la parcela de un creador genera denuncias de forma constante, se eleva el caso para su revisión. Si se determina repetidamente que un creador ha cometido infracciones, se restringen sus permisos de edición.
• Clasificación de parcelas. Como en Second Life, se permite a los creadores clasificar sus propias parcelas. La vista predeterminada oculta las parcelas clasificadas por encima de «General». Los jugadores pueden elegir ver contenido para adultos. Esto no evita las infracciones, pero reduce la exposición.

Consideraciones sobre la latencia

Si la revisión automatizada tarda entre 5 y 10 segundos por recurso, se produce un retraso perceptible entre el momento en que un creador coloca un objeto y aquel en que aparece para los demás jugadores. Opciones:

• Visualización local optimista. El creador ve lo que ha colocado inmediatamente. Los demás jugadores lo ven tras su aprobación. Si se rechaza el recurso, este desaparece y se notifica al creador.
• Biblioteca de recursos preaprobados. La mayoría de las colocaciones utiliza recursos previamente revisados de la biblioteca de la plataforma (incluidos recursos generados por IA que se revisaron durante su generación). Las cargas personalizadas pasan por el proceso de revisión. Esto permite que la mayoría de las colocaciones sean instantáneas.
• Tramitación acelerada basada en la reputación. Los creadores con un historial de contenido aprobado reciben aprobación automática para las nuevas colocaciones. Los creadores nuevos o marcados pasan por la revisión completa.

Rendimiento 3D en el navegador: cifras reales

Los presupuestos teóricos son útiles. El rendimiento medido en la práctica lo es aún más. Estas son cifras reales de escenas 3D en el navegador ejecutadas en hardware de producción.

Pruebas de renderizado

Escena de Three.js con 10.000 objetos instanciados (árboles y rocas, 500 triángulos cada uno):

• MacBook Pro M1 (Chrome, WebGL2): 58-60 fps
• Equipo de escritorio con RTX 3060 (Chrome, WebGL2): 60 fps fijos
• Portátil con Intel UHD 620 (Chrome, WebGL2): 25-35 fps
• iPhone 13 (Safari, WebGL2): 30-40 fps

Escena de Three.js con 100.000 briznas de hierba instanciadas (6 triángulos cada una, 600.000 triángulos en total):

• MacBook M1: 55 fps
• RTX 3060: 60 fps
• Intel UHD 620: 12 fps
• iPhone 13: 15 fps

Terreno de Babylon.js con 1 millón de triángulos, 4 niveles de LOD y físicas de Havok:

• MacBook M1 (WebGPU): 60 fps
• MacBook M1 (WebGL2): 45 fps
• RTX 3060 (WebGPU): 60 fps
• RTX 3060 (WebGL2): 55 fps

Escena de Gaussian splatting, 2 millones de splats (mediante gsplat.js):

• MacBook M1 (WebGL2): 30 fps
• RTX 3060 (WebGL2): 45 fps
• RTX 3060 (WebGPU): 60 fps

Mediciones de memoria

Escena mínima de Three.js (skybox, terreno y 100 objetos): 80-120 MB de memoria de GPU, 150-200 MB de heap de JS Babylon.js con físicas de Havok: 200-300 MB de memoria de GPU, 250-350 MB de heap de JS (Havok Wasm añade unos 50 MB) Límites de memoria de las pestañas del navegador (medidos, no documentados):

• Chrome para escritorio: suele bloquearse en torno a los 4 GB
• Chrome para Android: suele bloquearse en torno a 1-1,5 GB
• Safari para iOS: suele bloquearse en torno a 1 GB
• Firefox para escritorio: suele bloquearse en torno a 3-4 GB

Mediciones de red

Latencia de ida y vuelta de WebSocket (del navegador al edge de Cloudflare):

• Mismo continente: 10-30 ms
• Entre continentes: 80-200 ms
• Con Cloudflare Durable Objects: se añaden 5-10 ms para la activación del DO en la primera solicitud

Latencia de WebRTC DataChannel (de navegador a navegador mediante TURN):

• Misma ciudad: 5-15 ms
• Mismo continente: 20-50 ms
• Entre continentes: 100-250 ms

La latencia de WebTransport (HTTP/3 QUIC) es comparable a la de WebSocket, pero sin bloqueo de cabecera de línea, por lo que la latencia P99 es considerablemente mejor (sin interrupciones provocadas por un único paquete perdido).

Mediciones del tiempo de carga

Escena vacía de Three.js (solo la biblioteca): 350 ms hasta el primer fotograma Escena vacía de Babylon.js: 500 ms hasta el primer fotograma Modelo GLB de 1 MB mediante fetch + parse: 200-400 ms con banda ancha Textura KTX2, 1024x1024, Basis Universal: 50-100 ms para decodificarse en la GPU Malla comprimida con Draco, 50.000 triángulos: 30-80 ms para decodificarse en un Web Worker

Estas cifras confirman que el presupuesto de rendimiento de la sección de arquitectura es viable. Un equipo de escritorio de gama media puede renderizar una escena compleja de mundo abierto a 60 fps. El dispositivo móvil es la limitación: se necesitarían un LOD agresivo y una distancia de visión menor para mantener 30 fps en teléfonos.

La pila tecnológica completa

Uniendo todas las piezas, esta es la arquitectura de un mundo abierto multijugador para creadores basado en navegador:

Cliente (navegador)

Capa	Tecnología	Función
Renderizador	Babylon.js (WebGPU + WebGL2 como alternativa)	Renderizado de escenas, terreno, LOD y posprocesamiento
Terreno	Sistema personalizado de mapas de alturas + Babylon DynamicTerrain	Terreno transmitido por fragmentos con splatting
Físicas	Rapier (Wasm) o Havok (mediante Babylon)	Controlador de personaje, colisiones y raycasting
ECS	bitECS	Gestión de entidades para todos los objetos del mundo
Red	WebSocket + WebRTC DataChannel	Sincronización de estado, actualizaciones de posición y chat de voz
Estado	Yjs (CRDT)	Edición colaborativa del mundo y resolución de conflictos
Audio	Web Audio API	Audio espacial, ambiente y música
IU	Superposición HTML/CSS	HUD, inventario, chat y herramientas de creación
Workers	Web Workers	Descompresión de recursos, físicas y generación de terreno

Servidor

Capa	Tecnología	Función
Shards del mundo	Cloudflare Durable Objects	Estado autoritativo por fragmento y endpoints WebSocket
Almacenamiento de recursos	Cloudflare R2	Modelos GLB, texturas KTX2, mapas de alturas y audio
CDN de recursos	Cloudflare CDN (bucket público de R2)	Entrega desde la caché del edge de los recursos del mundo
Generación mediante IA	Instancias de GPU (Hetzner/Lambda/RunPod)	Generación de modelos 3D, terrenos y texturas
Flujo de recursos	Cloudflare Queue + Workers	Generación de LOD, optimización de mallas y conversión de formatos
Autenticación	Auth0	Identidad y permisos de los creadores
Base de datos	Cloudflare D1	Metadatos del mundo, inventarios de los creadores y permisos
Tiempo real	Cloudflare Durable Objects + Pub/Sub	Presencia de jugadores, chat y difusión de eventos

Flujo de datos

1. El jugador abre el mundo en su navegador
2. El cliente se autentica y se conecta al Durable Object más cercano correspondiente al fragmento de aparición
3. El DO envía el estado actual del fragmento (terreno + objetos + jugadores cercanos)
4. El cliente comienza a renderizar y solicita los fragmentos adyacentes a R2/CDN
5. A medida que el jugador se desplaza, el cliente se conecta a los DO adyacentes y se desconecta de los lejanos
6. El creador coloca un objeto: el cliente envía la edición al DO, el DO la valida y la difunde a todos los clientes conectados mediante un delta CRDT
7. El DO conserva el estado del fragmento en el almacenamiento con cada edición (aplicando debounce)
8. Los demás jugadores ven aparecer el nuevo objeto en 100-200 ms

Presupuesto de rendimiento

Para ofrecer una experiencia a 60 fps en un equipo de escritorio de gama media (RTX 3060 / Mac M1 / 16 GB de RAM):

Recurso	Presupuesto	Notas
Llamadas de dibujado	< 500 por fotograma	Agrupación, instanciación y LOD
Triángulos	< 2 millones por fotograma	El LOD mantiene esta cifra bajo control
Memoria de texturas	< 512 MB	Compresión KTX2, transmisión y agrupación de atlas
Memoria de geometría	< 256 MB	Búferes compartidos, agrupación y descarga agresiva
Heap de JavaScript	< 512 MB	ECS utiliza matrices tipadas, no objetos
Red	< 500 KB/s sostenidos	Compresión delta y filtrado por relevancia espacial
Carga inicial	< 10 MB, < 5 segundos	Carga progresiva, primero el terreno
Carga de fragmentos	< 200 KB, < 200 ms	Precarga de fragmentos adyacentes

Juegos de navegador de éxito y lo que demuestran

Los juegos de navegador no son un nicho. Constituyen uno de los mayores mercados de videojuegos. Poki recibe más de 100 millones de jugadores al mes. CrazyGames, Newgrounds e itch.io reciben varios millones más. Los juegos que triunfan en navegadores siguen patrones arquitectónicos concretos que merece la pena estudiar.

Juegos 3D para navegador disponibles hoy

Hordes.io: más de 200 jugadores en un MMO 3D persistente para navegador. WebGL personalizado, estilo low-poly y carga en menos de 5 segundos. Creado por un solo desarrollador.

**Hordes.io** es el MMO de navegador más relevante. Creado por un desarrollador en solitario con un renderizador WebGL personalizado, sitúa a más de 200 jugadores en un mundo 3D persistente con combate en tiempo real, gremios, clases y PvP. El juego completo carga en menos de 5 segundos. El mundo está dividido en zonas con un descarte agresivo. Los modelos de los jugadores son sencillos —de pocos polígonos y con sombreado plano—, pero los efectos de partículas y las animaciones hacen que el combate se sienta ágil. Hordes.io demuestra tres cosas: los MMO de navegador pueden admitir cientos de jugadores simultáneos en una misma escena, un desarrollador en solitario puede crear uno y los gráficos estilizados rinden mejor que los realistas en un navegador.

Krunker.io: 10 millones de jugadores mensuales, creado con Three.js, con un completo editor de mapas en el navegador y un mercado de contenido generado por los usuarios.

Krunker.io alcanzó un máximo de más de 10 millones de jugadores mensuales y fue adquirido por FRVR. Es un FPS de navegador con un completo editor de mapas, modos de juego personalizados, contenido generado por los usuarios y un mercado. Creado con Three.js, funciona a más de 60 fps incluso en hardware de gama baja gracias a su estilo artístico basado en bloques y a una optimización agresiva. El editor de niveles es especialmente relevante. Los jugadores crean mapas mediante un sistema de bloques similar al de los vóxeles, los comparten en el mercado y otros juegan en ellos. Es el ciclo de los mundos creados por usuarios en miniatura: construir algo, compartirlo y dejar que otros lo experimenten. Krunker demostró que el contenido 3D generado por los usuarios puede funcionar en un navegador si las herramientas de creación son lo bastante sencillas.

ev.io es un FPS de navegador creado con Babylon.js. Funciona bien en la mayoría del hardware, admite mapas personalizados y demuestra que el renderizador WebGL de Babylon puede manejar acción 3D trepidante en una pestaña del navegador. El juego utiliza compresión agresiva de texturas y entornos de pocos polígonos para mantenerse dentro de los límites de rendimiento.

Shell Shockers —con más de 5 millones de jugadores mensuales— es un juego de disparos multijugador 3D en el que juegas como un huevo. Creado con Three.js, gestiona multijugador en tiempo real con una detección de impactos ágil en el navegador. Su estilo artístico caricaturesco mantiene al mínimo los requisitos de recursos sin dejar de ofrecer un acabado pulido.

Townscaper: haz clic para colocar edificios y el sistema genera automáticamente calles, arcos y escaleras. Sin menús ni objetivos. Vendió más de 1 millón de copias gracias únicamente al placer de crear.

Townscaper no es un juego de navegador, pero su enfoque de la construcción de mundos es muy relevante. Los jugadores hacen clic para colocar edificios sobre una superficie de agua. El juego genera automáticamente detalles arquitectónicos, calles, arcos y escaleras según los patrones de colocación. Sin menús, ajustes ni objetivos. Solo hacer clic y construir. Vendió más de 1 millón de copias. La lección: a veces, las herramientas creativas más sencillas producen las experiencias más cautivadoras. Si logramos que colocar objetos en el mundo resulte tan inmediato como en Townscaper, los creadores pasarán horas construyendo.

Experiencias de A-Frame / 8th Wall. A-Frame —creado sobre Three.js— impulsa miles de experiencias 3D para la web. 8th Wall, la veterana plataforma WebAR adquirida por Niantic, demostró que la realidad aumentada compleja basada en cámaras funciona en navegadores móviles sin complementos, aunque Niantic anunció a finales de 2025 que está retirando progresivamente el servicio —las experiencias alojadas seguirán disponibles hasta 2027—. No son juegos, pero demuestran que el renderizado 3D complejo con físicas e interacción funciona en una pestaña del navegador sin complementos. Muchas de estas experiencias cargan en 2 o 3 segundos y funcionan en teléfonos de gama media.

Vuntra City: un laboratorio urbano procedimental en funcionamiento

Vuntra City es un proyecto nativo de UE5, no un juego de navegador, así que no es una referencia directa de rendimiento para nuestra arquitectura tecnológica. Aun así, es uno de los casos prácticos públicos más útiles para nuestra arquitectura de mundo abierto porque los diarios de desarrollo son inusualmente específicos sobre las concesiones de diseño de sistemas bajo la presión de una producción real.

Una conclusión importante es la política de detalle adaptada a la velocidad. En los vídeos sobre transporte y optimización, los desplazamientos a alta velocidad se trasladan por encima de los tejados, mientras que el detalle del mundo se reduce a medida que aumenta la velocidad para que el gestor de streaming no se sature con la carga y descarga constante de interiores (transporte rápido, técnicas de optimización). Esto encaja perfectamente con nuestro plan para el navegador, en el que la velocidad debería controlar directamente el radio de precarga, el alcance de activación de interiores y el presupuesto de generación por fotograma.

Otra conclusión es la separación estricta entre los datos topológicos y los objetos renderizados. La implementación de mapas y direcciones utiliza un controlador topológico global capaz de responder consultas de ubicación y dirección sobre regiones no cargadas (mapas y direcciones). Este es exactamente el patrón que necesitamos para el enrutamiento con autoridad del servidor, la búsqueda de puntos de interés y las consultas globales del mundo que no deberían depender de lo que un cliente concreto tenga cargado en memoria.

El trabajo con los PNJ también es muy relevante. El sistema de un millón de PNJ calcula globalmente un estado básico de sus horarios y solo simula comportamientos costosos en el espacio adyacente al jugador (un millón de PNJ persistentes, entre bastidores). Para nosotros, esto refuerza un modelo de simulación de dos niveles: un estado lejano barato y determinista, y un comportamiento cercano más rico dentro del área de interés.

Por último, el diseño de entornos de Vuntra City refuerza algo fácil de olvidar durante la planificación técnica: diseñar la distribución es diseñar el contenido. El proyecto evita la colocación aleatoria uniforme, utiliza valores atípicos ponderados para crear sorpresas e impulsa el descubrimiento mediante mapas y direcciones diegéticos en lugar de marcadores omnipresentes en el minimapa (los entornos procedimentales no tienen por qué ser aburridos, adonde vamos no necesitaremos minimapa).

Juegos de navegador que alcanzaron un éxito masivo

Agar.io (2015) demostró que el multijugador de navegador puede llegar a millones de personas. En su apogeo, tuvo más de 100 000 jugadores simultáneos repartidos entre sus servidores. El juego es 2D y mecánicamente sencillo —creces absorbiendo células más pequeñas—, pero la arquitectura de red gestiona una concurrencia masiva mediante particionamiento espacial. Cada servidor ejecuta una región del mundo del juego. Los jugadores solo reciben actualizaciones de las entidades dentro de su campo de visión. Es el mismo patrón de gestión de interés necesario para un mundo abierto 3D, pero en 2D.

Slither.io aprovechó el éxito de Agar.io y demostró que el modelo puede escalar. Alcanzó un máximo de 67 millones de usuarios activos mensuales. El juego utiliza WebSocket para sincronizar posiciones en tiempo real y particionamiento espacial para limitar el tráfico de red. Un detalle que merece la pena señalar: la detección de colisiones de Slither.io en el servidor se ejecuta con una frecuencia de ticks menor para los jugadores lejanos —5 Hz— que para los cercanos —30 Hz—. Esta frecuencia de ticks variable según la distancia se puede aplicar a un mundo abierto 3D.

Surviv.io era un battle royale de navegador que alcanzó los 50 millones de jugadores mensuales antes de ser adquirido por Kongregate. Ejecutaba una partida completa de battle royale para 80 jugadores íntegramente en el navegador, con físicas en red en tiempo real, entornos destructibles y recogida de objetos. El mapa se componía procedimentalmente a partir de plantillas de edificios prediseñadas, un patrón que podríamos utilizar para las estructuras colocadas por los creadores.

Zombs Royale ejecutaba un battle royale para 100 jugadores en el navegador, con tiempos de carga rápidos y una red ágil. Al igual que Surviv.io, demostró que un gran número de jugadores en juegos de navegador en tiempo real es viable comercialmente, no solo posible desde el punto de vista técnico.

El denominador común de todos estos éxitos de navegador es que cargan rápido —en menos de 5 segundos—, funcionan en cualquier dispositivo, tienen un estilo artístico sencillo pero coherente y su red está optimizada para la jugabilidad específica —particionamiento espacial, frecuencias de actualización variables y descarte agresivo del estado lejano—.

RuneScape: un MMO que dio el salto al navegador

RuneScape: un MMO completo con más de 20 años de contenido que funciona en una pestaña del navegador. Protocolo binario personalizado, streaming basado en casillas y 2000 jugadores simultáneos por servidor. La prueba de que los MMO de navegador funcionan a gran escala.

RuneScape es el caso práctico más importante para un mundo abierto de navegador porque sucedió de verdad. Jagex trasladó al navegador un MMO completo con 20 años de contenido.

RuneScape funcionaba originalmente como un applet de Java. Cuando los navegadores dejaron de admitir Java, Jagex reconstruyó el cliente en C++ y también lanzó un cliente HTML5/WebGL totalmente funcional. Old School RuneScape —la versión retro— ahora funciona íntegramente en el navegador mediante un cliente compilado con Emscripten a WebAssembly. El juego gestiona grandes mundos persistentes, multijugador en tiempo real con cientos de jugadores por servidor, una economía con un gran mercado plenamente funcional —una casa de subastas— y 23 habilidades con sistemas de progresión profundos.

Detalles técnicos importantes:

• El mundo está dividido en cuadrados de mapa —regiones de 64x64 casillas—. El cliente carga una cuadrícula de 13x13 regiones alrededor del jugador —104x104 casillas visibles—. Las regiones que quedan fuera de esta cuadrícula se descartan por completo.
• El terreno se basa en casillas con valores de altura en cada esquina. Las capas superpuestas del terreno —caminos, orillas del agua y transiciones a playas— utilizan un sistema de formas con 12 variantes de rotación por forma. Es más limitado que un mapa de alturas, pero resulta extremadamente compacto y rápido de transmitir.
• El protocolo de red es binario y personalizado sobre WebSocket. Cada tipo de paquete tiene una estructura definida. Las actualizaciones de posición de los jugadores utilizan 2 bytes para las coordenadas del cuadrado del mapa y una codificación de longitud variable para el tipo de movimiento. El chat, el comercio y los eventos de combate tienen sus propios formatos binarios compactos. Todo el protocolo está fuertemente optimizado para minimizar el ancho de banda.
• El renderizado de objetos utiliza un sistema de modelos en el que el servidor envía el ID de un modelo y el cliente renderiza el modelo almacenado en caché. La mayoría de los modelos se cargan una vez y se reutilizan. Esto significa que el mundo se transmite como metadatos —qué modelo va en cada lugar— en vez de transmitir geometría.
• Cada instancia de servidor admite 2000 jugadores simultáneos en todo el mundo del juego. El mundo no está fragmentado espacialmente. Un único proceso de servidor gestiona a todos los jugadores, todos los PNJ y toda la lógica del juego con un tick de 600 ms. Esto funciona porque la lógica del juego es sencilla en cada tick: procesar las acciones de los jugadores, actualizar la IA de los PNJ, resolver el combate y difundir los cambios de estado.

Lo que RuneScape demuestra para nuestro caso: un MMO completo con estado persistente del mundo, miles de jugadores, sistemas de juego complejos y una economía real puede funcionar en una pestaña del navegador. La descarga del cliente ocupa menos de 50 MB, carga en pocos segundos y funciona en portátiles. Si un MMO de Java con 20 años de antigüedad puede realizar la transición, un mundo diseñado específicamente para el navegador tendrá aún menos limitaciones.

Dónde no encaja el enfoque de RuneScape: el renderizado de RuneScape es isométrico y de cámara fija, no 3D en primera o tercera persona. La fidelidad visual es baja según los estándares modernos. Además, los creadores no pueden editar el mundo. Sin embargo, la arquitectura de red, el streaming basado en casillas y la prueba de que los MMO de navegador retienen jugadores durante décadas son directamente relevantes.

Habbo Hotel: espacios sociales que han perdurado 25 años

Habbo Hotel se lanzó en 2000 y sigue funcionando. Es un mundo social isométrico 2D en el que los usuarios crean y decoran habitaciones, visitan las de otras personas y socializan. En su apogeo, tuvo 9 millones de usuarios mensuales. La experiencia completa funcionaba en Flash —ahora en HTML5 tras la desaparición de Flash—.

Habbo es importante por el tiempo que ha logrado mantener activa una comunidad de creadores. El sistema de habitaciones es, en la práctica, una versión 2D de lo que estamos construyendo: los usuarios colocan muebles en una cuadrícula, personalizan la distribución e invitan a otros a visitarla. El modelo económico —los usuarios compran muebles virtuales con dinero real— ha generado más de 1000 millones de dólares en ingresos desde su lanzamiento.

Lo que enseña Habbo:

• Los espacios basados en habitaciones con interiores creados por los usuarios pueden funcionar como plataforma social durante décadas si las herramientas de creación son sencillas y las funciones sociales son sólidas.
• La economía de muebles virtuales mantiene la interacción a largo plazo. Los usuarios compran, intercambian y coleccionan objetos. Los objetos no tienen ninguna utilidad jugable. Son pura expresión personal y estatus.
• La moderación de espacios sociales requiere una inversión constante. Habbo ha atravesado varias crisis de moderación. El filtrado automatizado de contenido, los moderadores humanos y las denuncias de la comunidad constituyen el enfoque viable mínimo.
• La transición de Flash a HTML5 —completada en torno a 2020-2021— demostró que un gran mundo social puede migrar su tecnología de renderizado sin perder a su comunidad. A los usuarios les importan sus habitaciones y sus amigos, no la tecnología subyacente.

Among Us y los juegos sociales espaciales

Among Us no es un mundo abierto, pero su éxito reveló algo importante sobre los espacios multijugador: los jugadores quieren estar juntos en un lugar, no solo participar juntos en un juego. Los mods de chat de proximidad espacial que se volvieron virales demostraron que estar en la misma sala virtual con audio direccional transforma el multijugador, que pasa de ser una mecánica de juego a convertirse en una experiencia social. Funciones sociales espaciales que mejoran un mundo de creadores:

• Chat de voz por proximidad, donde el volumen disminuye con la distancia. Acércate a alguien para hablar. Aléjate y su voz se desvanecerá. Esto crea grupos sociales naturales sin necesidad de gestionar canales de voz.
• Sistemas de emotes y gestos que permiten a los jugadores expresarse sin usar la voz. Un saludo, un baile, un gesto para señalar. Son baratos de implementar (animaciones en el avatar del jugador) y aumentan de forma desproporcionada la interacción social.
• Actividades compartidas que suceden dentro del mundo (no mediante menús) convierten un espacio en un lugar de encuentro. Si dos creadores pueden sentarse en una mesa virtual y observar juntos modelos 3D, el mundo tiene una razón de ser más allá de mostrar contenido estático.

Juegos de navegador que triunfaron en Poki y CrazyGames

Poki y CrazyGames suman más de 150 millones de jugadores mensuales. Los juegos con mejores resultados en estas plataformas ofrecen pistas sobre lo que funciona específicamente en el navegador.

Patrones de mayor rendimiento en los portales de juegos de navegador:

• Juego instantáneo (menos de 3 segundos hasta poder interactuar). Sin necesidad de iniciar sesión. Sin necesidad de tutorial. El juego debe entenderse en los 5 segundos posteriores a entrar.
• Sesiones flexibles. Los jugadores entran durante 2 minutos o 2 horas. El juego se adapta a ambas posibilidades. Para un mundo de creadores, esto significa que debe poder explorarse sin comprometerse a una sesión. Pasea, descubre cosas interesantes y vete. O quédate y construye durante horas.
• Compatibilidad con móviles. Más del 60 % del tráfico de Poki procede de dispositivos móviles. Un mundo de navegador que solo funciona en equipos de escritorio pierde a la mayoría de sus visitantes potenciales.
• Funciones sociales que no requieran amigos. Tablas de clasificación, reacciones al contenido de otros jugadores y funciones asíncronas (ver lo que construyeron otros jugadores sin estar conectados al mismo tiempo).

Los juegos 3D más exitosos de estos portales (como Shell Shockers, 1v1.LOL y Smash Karts) mantienen bajo el número de polígonos, usan texturas sencillas y ofrecen una alta tasa de fotogramas. Demuestran que los jugadores aceptan gráficos sencillos si la experiencia es fluida y responde bien.

Plataformas de creación basadas en el navegador

Hubs de Mozilla (ahora mantenido por la comunidad). Espacios 3D multiusuario en el navegador, creados con Three.js y A-Frame. Admite chat de voz, avatares y objetos compartidos. No es un mundo abierto (se basa en salas), pero su arquitectura de red y renderizado es relevante. Mozilla publicó su código como software libre antes de cerrar el servicio alojado, por lo que todo el código fuente está disponible para estudiarlo. GitHub.

Hyperfy. Una plataforma de metaverso web que se ejecuta íntegramente en el navegador. Renderizado con Three.js, multijugador, personalización de avatares y construcción de mundos. Se acerca más a nuestro objetivo que Hubs porque pone énfasis en las herramientas de creación. Los mundos se cargan en una pestaña del navegador sin necesidad de descargar nada. hyperfy.io.

Ethereal Engine (antes XREngine). Motor de código abierto para mundos multiusuario, creado con Three.js y bitECS. Admite WebXR, audio espacial y edición de mundos. Incluye arquitectura ECS, capa de red y herramientas de edición. Es el proyecto de código abierto existente que más se aproxima a lo que describimos. Conviene estudiar cómo integra bitECS con Three.js para gestionar entidades y cómo su sistema de red maneja el estado espacial. GitHub.

Dusk (antes Rune). SDK de juegos multijugador para juegos web. Se ocupa de la capa de red para que los desarrolladores puedan centrarse en la jugabilidad. Su método de sincronización emplea un estado predicho con reconciliación del servidor, el modelo estándar para un multijugador con buena capacidad de respuesta. El SDK abstrae la complejidad del código de red con reversión. Conviene estudiar su experiencia de desarrollo.

Niantic Studio. Un editor visual para navegador y un motor de juegos web (sucesor de las herramientas de 8th Wall) para crear experiencias 3D y XR que otras personas pueden visitar desde un navegador. Demuestra que los creadores sin conocimientos técnicos pueden construir escenas 3D en un navegador si las herramientas son accesibles. (Niantic escindió su trabajo geoespacial en Niantic Spatial y vendió su negocio de videojuegos, incluido Pokemon GO, a Scopely en 2025).

PlayCanvas Editor. No es un juego en sí, pero el editor 3D en la nube de PlayCanvas demuestra que las herramientas colaborativas de construcción de mundos pueden ejecutarse en el navegador. Varios miembros de un equipo editan simultáneamente la misma escena. El editor comunica los cambios mediante una capa de sincronización en tiempo real. Este es el modelo de creación colaborativa que necesitaríamos, pero usando nuestro mundo como lienzo en lugar de un editor de juegos.

Plataformas de creación nativas (lecciones para el navegador)

Estas plataformas se ejecutan como aplicaciones nativas, pero sus decisiones de diseño sobre las herramientas de creación, la persistencia del mundo y las dinámicas sociales son directamente aplicables.

Roblox: más de 80 millones de usuarios diarios y 740 millones de dólares pagados a creadores en 2023. La creación se lleva a cabo dentro del motor. El descubrimiento es social. Es el modelo de negocio que demuestra que las plataformas de creación pueden sostenerse por sí mismas.

Roblox es la referencia más importante para un mundo de creadores. Más de 80 millones de usuarios activos diarios. Los creadores construyen experiencias 3D completas (juegos, espacios sociales y tiendas) que visitan otros jugadores. La plataforma se ocupa del alojamiento, las redes, el descubrimiento y la monetización.

Lo que Roblox hace bien:

• La creación se lleva a cabo dentro del motor. Roblox Studio es el mismo entorno que experimentan los jugadores. Los creadores prueban su trabajo al instante. No hay ningún ciclo de exportar, subir y esperar. Para un mundo de navegador, el editor debería ser el propio mundo.
• La programación es accesible. Lua (el lenguaje de programación de Roblox) es tan sencillo que los niños pueden aprenderlo. Es posible crear comportamientos complejos, pero no es obligatorio. Es fácil empezar y las posibilidades son enormes.
• El descubrimiento es social. Encuentras experiencias porque tus amigos están jugando a ellas. La página de inicio muestra experiencias populares. Para un mundo de navegador, el propio mundo es la superficie de descubrimiento. Exploras y encuentras cosas mientras caminas.
• La monetización funciona. Los creadores ganan dinero real (Roblox pagó 740 millones de dólares a creadores en 2023). Esto atrae un esfuerzo creativo serio. Sin incentivos económicos, las plataformas de creación se convierten en proyectos de aficionados que acaban desapareciendo.
• El motor de renderizado de Roblox es propio y se ejecuta en una aplicación nativa, no en un navegador. Sin embargo, los límites de recursos de cada experiencia son modestos para los estándares actuales (se recomienda un máximo de 100 MB). La mayoría de las experiencias exitosas de Roblox usan arte estilizado con pocos polígonos, lo que encaja con las limitaciones de renderizado del navegador.

Fortnite Creative / UEFN (Unreal Editor for Fortnite). Epic puso el editor completo de Unreal Engine a disposición de los creadores de Fortnite. El resultado es una plataforma donde las personas construyen islas (mundos independientes) con herramientas profesionales. Fortnite se ocupa del alojamiento, el multijugador y la distribución.

Conclusiones relevantes:

• Las herramientas profesionales atraen contenido profesional. UEFN produce experiencias visualmente impresionantes porque los creadores tienen acceso a todas las capacidades de UE5. La contrapartida es la complejidad. UEFN tiene una curva de aprendizaje pronunciada.
• Las instancias basadas en islas (cada creación es un mundo separado) evitan los problemas de moderación y los conflictos propios de un único mundo compartido. Sin embargo, también impiden que los creadores descubran de forma natural el trabajo de los demás al explorar. Las islas se visitan mediante menús, no caminando.
• El modelo de negocio funciona. El programa de creadores de Fortnite paga en función de la interacción. Los creadores más destacados ganan millones al año. Una vez más, los incentivos económicos impulsan la calidad.

Dreams (Media Molecule / PlayStation). Dreams proporcionó a los jugadores de consola un conjunto completo de herramientas de creación 3D (modelado, animación, música, lógica y diseño de niveles) y una plataforma para compartir sus creaciones. Es la plataforma de creación más ambiciosa jamás construida en cuanto a la profundidad de sus herramientas.

Conclusiones relevantes:

• Modelado basado en escultura en lugar de edición de polígonos. Los creadores dan forma a volúmenes blandos con herramientas para mover, agarrar y suavizar, de forma parecida a ZBrush, pero más intuitiva. La curva de aprendizaje es suave. Este enfoque se adapta bien a la creación en el navegador porque no exige comprender los vértices ni los mapas UV.
• Todo es un recurso compartido. Si alguien crea un modelo de árbol, cualquiera puede utilizarlo en su propia creación (con atribución). Esto genera un ecosistema creativo acumulativo donde cada creación aumenta el valor de la plataforma.
• Dreams tuvo dificultades comerciales pese a recibir elogios de la crítica. El problema fue la distribución: estaba limitado a PlayStation y las herramientas de creación eran tan profundas que la mayoría de los jugadores nunca pasó de consumir contenido. La lección es que las herramientas de creación deben ser lo bastante sencillas para que la mayoría de los usuarios las prueben, aunque solo una minoría llegue a convertirse en constructores serios.

Core (Manticore Games). Una plataforma gratuita para crear y jugar a juegos multijugador, construida sobre Unreal Engine con un editor simplificado. El editor de Core se ejecuta como una aplicación nativa, pero su filosofía es relevante. Las plantillas y los scripts compartidos por la comunidad permiten a los principiantes montar juegos a partir de componentes prefabricados. Los creadores avanzados pueden escribir scripts Lua para definir comportamientos personalizados. Core tuvo dificultades para atraer a un público amplio, en parte porque los juegos debían ejecutarse mediante el lanzador de Core. Una versión para navegador no tendría este obstáculo.

VRChat y Rec Room son plataformas sociales donde los creadores construyen espacios que visitan otras personas. VRChat utiliza Unity y funciona en PC y realidad virtual. Rec Room funciona en todo tipo de dispositivos, incluidos los móviles. Ambas demuestran que los mundos 3D generados por usuarios pueden sostener comunidades numerosas. VRChat es más impresionante desde el punto de vista técnico (shaders personalizados y avatares complejos). Rec Room es más accesible (herramientas de creación dentro de la aplicación, gráficos más sencillos y compatibilidad con más plataformas). Para un mundo de navegador, el enfoque de Rec Room, con herramientas de creación sencillas dentro de la aplicación, es más aplicable que el flujo de trabajo de VRChat basado en herramientas externas.

Second Life: lanzado en 2003, sigue activo con más de 200 000 usuarios diarios. Creado íntegramente por los usuarios. Propiedad basada en parcelas y una economía virtual valorada en unos 500 millones de dólares al año. 20 años de lecciones sobre persistencia y moderación.

Second Life es el precursor de todos los mundos de creadores. Se lanzó en 2003 y sigue activo, con más de 200 000 usuarios activos diarios. Todo el mundo ha sido creado por los usuarios. Las tierras se poseen y se comercializan. Los creadores venden objetos, ropa y edificios. El lenguaje de programación del mundo (LSL) permite crear contenido interactivo.

Lo que Second Life nos enseña después de más de 20 años:

• La persistencia importa más que los gráficos. El aspecto visual de Second Life está anticuado, pero el mundo persiste. Las creaciones permanecen donde las colocas. Las relaciones y la historia se acumulan. Esta persistencia es lo que hace que la gente regrese.
• La economía impulsa la creación. Se estima que el PIB de Second Life asciende a 500 millones de dólares al año. Los creadores construyen porque pueden vender. Sin incentivos económicos, el volumen y la calidad del contenido creado por los usuarios disminuyen.
• El contenido generado por los usuarios requiere infraestructura de moderación. Second Life ha afrontado 20 años de desafíos de moderación. Cualquier plataforma donde los usuarios puedan colocar contenido arbitrario en un espacio compartido necesita análisis automatizados, herramientas de denuncia y revisión humana.
• La organización espacial basada en terrenos funciona. Second Life divide su mundo en parcelas propiedad de los usuarios. Cada parcela tiene un límite de prims (objetos). Esto evita de forma natural que un solo creador consuma todos los recursos. Para un mundo de navegador, el patrón equivalente sería la propiedad basada en sectores con límites de objetos por sector.

Análisis comparativo: qué nos enseña cada juego

Juego	Lección clave	Tecnología aplicable	Riesgo si se ignora
Skyrim	Streaming por sectores con una cuadrícula de celdas	Terreno basado en mapas de altura, niveles de LOD, separación entre interiores y exteriores	El mundo no cabe en la memoria del navegador
The Witcher 3	Composición del mundo por capas a cargo de equipos independientes	Streaming sensible al contenido, renderizado mediante impostores	Los creadores no pueden trabajar de forma independiente
Breath of the Wild	Las reglas sistémicas superan al contenido guionizado	Sistema de interacción de materiales, jugabilidad basada en físicas	El mundo parece estático y sin vida
GTA V	La vida ambiental hace que los mundos parezcan reales	Sistemas de comportamiento de PNJ, tráfico, ciclo horario	El mundo del creador parece un museo vacío
Elden Ring	Variación de densidad y reutilización de recursos	Biblioteca de recursos modulares, zonas dispersas y densas	Queda demasiado vacío o resulta demasiado caro llenarlo
No Man's Sky	Generación procedimental para el lienzo, contenido de los creadores para darle alma	Terreno basado en semillas, modelo de datos compacto para bases	Terreno infinito pero aburrido
Minecraft	Mundo totalmente editable, herramientas sencillas, profundidad infinita	Streaming por sectores, compresión mediante paletas, protocolo de edición de bloques	Los creadores no pueden remodelar el propio mundo
Roblox	La creación ocurre dentro del motor y la economía impulsa la calidad	Editor dentro del mundo, monetización para creadores	Nadie crea porque no hay ningún incentivo
Krunker.io	El CGU en el navegador funciona a gran escala con herramientas sencillas	Renderizado con Three.js, editor basado en vóxeles, mercado	Herramientas de creación demasiado complejas para creadores ocasionales
Hordes.io	Más de 200 jugadores en 3D en el navegador; viable para un desarrollador en solitario	WebGL personalizado, descarte espacial, arte estilizado	Sobredimensionar la capa multijugador
Vuntra City (referencia nativa)	El streaming sensible a la velocidad y la simulación del mundo en dos niveles mantienen coherente una enorme ciudad procedimental	Política de LOD vinculada a la velocidad, capa de consultas topológicas, simulación programada a larga distancia + comportamiento en campo cercano	El desplazamiento a alta velocidad provoca apariciones repentinas y picos de simulación
Agar.io / Slither.io	La partición espacial permite una concurrencia masiva	Frecuencia de actualización variable según la distancia, gestión de interés	La red colapsa a gran escala
Second Life	La persistencia y la economía mantienen comunidades durante 20 años	Propiedad basada en parcelas, presupuestos de objetos, mercado	No hay retención a largo plazo
Dreams	La creación basada en escultura es más intuitiva que la edición de polígonos	Modelado basado en volúmenes, biblioteca compartida de recursos	Las herramientas de creación parecen un programa CAD
Fortnite Creative	Las herramientas profesionales atraen contenido profesional	Capacidades completas de edición dentro de la plataforma	El techo de calidad del contenido es demasiado bajo
RuneScape	Un MMO completo funciona en el navegador mediante Wasm y protocolos binarios	Emscripten, protocolo WebSocket binario personalizado, streaming por teselas	Subestimar lo que pueden manejar los navegadores
Habbo Hotel	La creación sencilla de salas mantiene una comunidad durante 25 años	Colocación basada en cuadrícula, economía de mobiliario virtual	Complicar en exceso las herramientas de creación

Los juegos más relevantes para nuestro caso concreto —basado en navegador, centrado en creadores y multijugador— son Minecraft (mundo editable, datos compactos), Roblox (creación dentro del motor, economía), Krunker (CGU en el navegador a gran escala) y Hordes.io (arquitectura de MMO para navegador). Los títulos AAA (Skyrim, BotW, The Witcher 3) enseñan sobre renderizado y streaming. Los éxitos de navegador (Agar.io, Slither.io, Surviv.io) enseñan sobre redes a gran escala. Las plataformas para creadores (Roblox, Dreams, Second Life) enseñan sobre dinámicas comunitarias. Vuntra City añade una referencia actual y a nivel de implementación para el streaming sensible a la velocidad, la navegación diegética y los patrones de simulación de millones de agentes en una ciudad procedimental moderna.

Cómo serían Skyrim y The Witcher en un navegador

Seamos concretos. Si tomáramos Carrera Blanca de Skyrim y la reconstruyéramos para distribuirla a través del navegador:

Terreno: El área alrededor de Carrera Blanca mide aproximadamente 2 × 2 km. Con nuestro tamaño de sector (64 m), son alrededor de 32 × 32 = 1024 sectores. A 2-4 KB por mapa de altura de cada sector, eso supone 2-4 MB de datos de terreno. Las texturas del terreno (hierba, tierra, roca y nieve), como teselas de un atlas KTX2, podrían añadir otros 5 MB. Terreno total: menos de 10 MB para toda la región.

Estructuras: La propia Carrera Blanca tiene quizá entre 40 y 50 edificios. Cada edificio, como GLB optimizado (3 niveles de LOD), podría ocupar entre 200 y 500 KB en su máximo nivel de detalle. Pero solo se necesita el máximo detalle para los 5-10 edificios más cercanos. El resto utiliza un LOD medio o bajo (50-100 KB cada uno). Total de estructuras visibles en un momento dado: 2-5 MB.

Vegetación: Todos los árboles y la hierba que rodean Carrera Blanca en Skyrim están instanciados. Harían falta quizá 10 modelos de árbol únicos (200 KB cada uno con LOD completo, 20 KB como impostores en billboard) y un sistema de hierba que genere las briznas en la GPU a partir de un mapa de densidad. Total de recursos de vegetación: 2-3 MB. Los datos de instanciación (posiciones, rotaciones y escalas) para un área de 5 × 5 sectores: menos de 500 KB.

PNJ: Carrera Blanca tiene aproximadamente 70 PNJ con nombre, además de los guardias. Cada avatar con calidad media: 100-200 KB. Pero solo hay entre 10 y 20 visibles en un momento dado. Total de datos de renderizado de PNJ: 2-4 MB.

Total general para un área de la escala de Carrera Blanca visible en un momento dado: 15-25 MB. Es perfectamente viable en un navegador. La carga inicial mostraría el terreno y las estructuras principales en 3-5 segundos con una conexión de banda ancha, y los detalles se completarían durante los segundos siguientes.

Novigrado, de The Witcher 3, es más grande y densa, pero se aplican los mismos principios. Harían falta un LOD y un streaming más agresivos, pero el total de datos visibles en cada momento seguiría dentro de los límites de memoria del navegador.

Qué crearíamos primero

Un mundo abierto completo es un proyecto de varios años. Esta es la ruta para poner rápidamente algo real en manos de los creadores:

Fase 1: Isla compartida (3 meses). Un único sector de terreno (una isla de 512 × 512 m) con terreno basado en mapa de altura, agua, vegetación básica y ciclo de día y noche. Multijugador mediante Durable Objects (hasta 50 usuarios simultáneos). Los creadores pueden colocar recursos 3D generados por IA desde su biblioteca actual de Cinevva. Puede entenderse como un diorama compartido.

Fase 2: Mundo ampliable (3 meses). Streaming por sectores para un mundo de 4 × 4 km. Parcelas propiedad de creadores en las que disponen de permisos de edición. Sistema de LOD para el terreno y los objetos. Estado persistente del mundo. Hasta 200 usuarios simultáneos repartidos por el mundo.

Fase 3: Mundo vivo (6 meses). Esculpido de terreno asistido por IA. Vegetación y atmósfera procedimentales. Sistema de misiones y eventos para que los creadores puedan construir experiencias interactivas, no solo escenas estáticas. Chat de voz. Personalización de avatares. El mundo se convierte en un destino, no en una demostración.

Preguntas abiertas

Estilo artístico. Un estilo estilizado (low-poly, cel shading) es más barato de renderizar y tolera mejor los recursos generados por IA. El realismo exige recursos de mayor calidad y más presupuesto de renderizado. Skyrim funcionaba a pesar de sus gráficos anticuados porque su dirección artística era coherente. BotW se ve magnífico en hardware de nivel tableta porque el estilo cel shading oculta el bajo número de polígonos. Minecraft utiliza texturas de 16 × 16 y es uno de los juegos más reconocibles de la historia. Tanto Krunker.io como Hordes.io triunfan con gráficos estilizados sencillos en el navegador. Las pruebas favorecen de manera abrumadora una dirección estilizada para un mundo de navegador. Debemos elegir pronto una identidad visual específica y garantizar la coherencia de todos los recursos generados por IA.

Persistencia del mundo frente a instancias. ¿Todo el mundo comparte un único mundo (como en un MMO o Second Life) o cada creador obtiene su propia instancia que otros pueden visitar (como en los servidores de Minecraft o las islas de Fortnite)? La tecnología admite ambas opciones, pero las dinámicas sociales son completamente distintas. El mundo compartido y persistente de Second Life favorece los descubrimientos fortuitos: mientras caminas, te encuentras por casualidad con el trabajo de otras personas. Las islas instanciadas de Fortnite requieren un menú o un sistema de portales para descubrirlas. Roblox utiliza un enfoque basado en un centro: los juegos están separados, pero se exploran y descubren mediante una interfaz compartida. Podría funcionar un modelo híbrido: un supramundo compartido y persistente donde los creadores posean parcelas —como las de Second Life—, con la opción de acceder a experiencias independientes mediante portales.

Profundidad de las herramientas de creación. Dreams demostró que las herramientas de creación avanzadas impresionan a los críticos, pero intimidan a los usuarios. Townscaper demostró que unas herramientas mínimas pueden vender un millón de copias. Roblox Studio se sitúa en un punto intermedio: lo bastante sencillo para niños y lo bastante potente para profesionales. El editor de vóxeles de Krunker es aún más sencillo. Para un mundo de navegador, deberíamos comenzar con la sencillez de Townscaper —colocar objetos que se alinean y conectan automáticamente— y añadir profundidad con el tiempo. La experiencia inicial de colocar el primer objeto en el mundo debería durar menos de 30 segundos.

Economía. Roblox, Second Life y Fortnite Creative demuestran que el incentivo económico es lo que convierte un juguete en una plataforma. Sin una forma de que los creadores ganen dinero con su trabajo, los más talentosos crearán en otro lugar. Esto no tiene que estar disponible desde el primer día, pero la arquitectura debería admitirlo: propiedad de objetos, seguimiento de visitas y atribución a creadores.

Móviles. Aún faltan años para que WebGPU sea fiable en dispositivos móviles. Una experiencia móvil tendría que ser una versión reducida: terreno más sencillo, menos objetos y una distancia de visión menor. Merece la pena estudiar el enfoque de Rec Room, que funciona en todo tipo de dispositivos mediante calidad adaptativa. Otra opción es publicar una aplicación nativa para móviles y mantener la experiencia completa en el navegador.

Moderación. Un mundo abierto donde cualquiera pueda colocar cualquier cosa es una pesadilla de moderación. Second Life lleva 20 años lidiando con ello. Cada recurso colocado debe someterse a una revisión automatizada del contenido antes de hacerse visible para los demás. Esto añade latencia al proceso creativo, pero no es negociable. También deberíamos plantearnos clasificaciones de contenido por parcela —como el sistema General/Moderado/Adulto de Second Life— para que los creadores puedan elegir los límites de su contenido.

Interacciones sistémicas. Tanto BotW como Minecraft muestran que los sistemas de interacción basados en materiales crean mundos exponencialmente más interesantes que la colocación de objetos estáticos. Si un creador coloca un puente de madera y otro enciende una hoguera cerca, ¿debería arder el puente? Si alguien coloca una presa, ¿debería acumularse el agua detrás? Estas interacciones hacen que el mundo parezca vivo, pero exigen reglas coherentes de física y materiales para todo el contenido de los creadores. Decidir hasta dónde llegar con el diseño sistémico es una decisión arquitectónica temprana.

Conclusiones clave

Los mundos abiertos 3D en el navegador son viables hoy. Hordes.io admite a más de 200 jugadores en 3D dentro de un navegador. Krunker.io llegó a tener 10 millones de jugadores mensuales con un editor completo de mapas 3D. Los juegos .io demostraron que el multijugador en el navegador puede escalar hasta millones de usuarios. La tecnología no es especulativa.

El renderizado está listo. Three.js y Babylon.js gestionan escenas 3D comparables a las de los juegos AAA de principios de la década de 2010. WebGPU habilita shaders de cómputo para el terreno y la vegetación. Los motores de físicas Wasm se ejecutan a una velocidad entre 2 y 3 veces inferior a la nativa. Un área de la escala de Carrera Blanca cabe en 15-25 MB de datos visibles.

La red está lista. Cloudflare Durable Objects proporciona servidores autoritativos por sector en el edge. Los CRDT gestionan la edición colaborativa sin conflictos. La partición espacial —demostrada por todos los juegos, desde Agar.io hasta Skyrim— mantiene el tráfico de red en niveles manejables con cientos de jugadores simultáneos.

Los mundos abiertos AAA (Skyrim, The Witcher 3, BotW, Elden Ring, Minecraft y No Man's Sky) no son solo referentes gráficos. Son manuales sobre streaming por sectores, gestión de LOD, generación procedimental, diseño sistémico y composición de mundos. Cada técnica que utilizan tiene un equivalente compatible con el navegador.

Las plataformas para creadores (Roblox, Second Life, Fortnite Creative y Dreams) enseñan las lecciones sociales y económicas. La creación debe ocurrir dentro del mundo, no en una herramienta externa. Los incentivos económicos impulsan la calidad. La persistencia genera apego. Las herramientas sencillas llegan a más creadores que las potentes.

El proceso creativo es donde Cinevva tiene ventaja. Ya generamos recursos 3D, texturas y audio. La pieza que falta es conectar ese proceso con un sistema de colocación en el mundo. El contenido generado por IA llena el mundo. La selección y disposición por parte de los creadores le da alma.

El resultado no sería Skyrim en un navegador. Se parecería más a la intersección entre Minecraft —mundo editable—, Roblox —economía de creadores— y BotW —interacciones sistémicas—, ejecutándose en una pestaña del navegador con herramientas de creación basadas en IA. La tecnología necesaria para construirlo existe. La cuestión es la ejecución.

Artículos de investigación y referencias académicas

Las técnicas de esta guía no se han inventado desde cero. Se basan en décadas de investigación. Estos son los artículos más importantes para cada subsistema, con notas sobre cómo se aplican a un mundo abierto de navegador.

Generación y renderizado de terreno

"Un sintetizador de imágenes" -- Ken Perlin (SIGGRAPH 1985). DOI. El artículo que presentó el ruido de Perlin. Todos los generadores de terreno procedimental de todos los juegos desde 1985 tienen su origen aquí. La función de ruido produce una aleatoriedad suave que, al combinarse en octavas —movimiento browniano fraccional—, genera mapas de altura de aspecto natural. El ruido simplex (Perlin, 2001) es su sucesor más rápido. Para nuestro proceso de generación de terreno, esta es la base: la generación de mapas de altura basada en ruido se ejecuta en un shader de cómputo WebGPU a velocidades interactivas.

"Texturizado y modelado: un enfoque procedimental" -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3.ª edición de 2003). El manual de referencia sobre generación procedimental. Los capítulos de Musgrave sobre modelado de terreno, incluido el terreno multifractal con características similares a la erosión, constituyen la base directa de los generadores de terreno modernos para videojuegos. Los parámetros de fBm —lacunaridad, persistencia y número de octavas— descritos aquí son los mismos que ofreceríamos a los creadores para personalizar el terreno.

"Clipmaps de geometría: renderizado de terreno mediante cuadrículas regulares anidadas" -- Losasso and Hoppe (SIGGRAPH 2004). DOI. Este artículo resolvió cómo renderizar terrenos enormes a velocidades interactivas mediante anillos concéntricos de LOD —clipmaps—. La malla del terreno es un conjunto fijo de cuadrículas anidadas centradas en la cámara. Cuando la cámara se mueve, las cuadrículas se desplazan y actualizan. Esta es la técnica recomendada en nuestra sección sobre terreno para WebGL 2, y funciona porque la carga de trabajo de la GPU es constante independientemente del tamaño del mundo. La implementación original es anterior a WebGL, pero se adapta directamente a él. «Simulación y visualización rápidas de erosión hidráulica en GPU» -- Mei, Decaudin, Hu (2007). PDF. Trasladó la erosión hidráulica de un proceso sin conexión limitado por la CPU a un cálculo en tiempo real mediante GPU. El modelo de simulación de aguas someras del artículo (que trata el agua como un campo de alturas y calcula el flujo entre las celdas de una cuadrícula) se ejecuta en un shader de cómputo. En nuestro pipeline, la erosión mediante GPU en el servidor puede transformar terrenos generados con ruido en paisajes geológicamente plausibles en menos de un segundo, haciendo que el terreno generado por IA parezca esculpido a mano.

«Renderizado en tiempo real de planetas generados proceduralmente» -- Enfoques híbridos procedentes de las charlas de No Man's Sky en la GDC y las explicaciones de Sean Murray. Aunque no se trata de un único artículo, la charla de la GDC 2017 «Building Worlds Using Maths», de Innes McKendrick (Hello Games), detalla cómo No Man's Sky genera terrenos a escala planetaria mediante funciones de ruido apiladas, representación de vóxeles con marching cubes y generación en la GPU. Es directamente relevante para nuestro enfoque de terrenos procedurales, especialmente para generar accidentes geográficos que los mapas de alturas no pueden representar (cuevas, arcos).

«C-DBLOD: LOD híbrido para el renderizado de terrenos» -- Filip Strugar (2014). Artículo. Una mejora de los clipmaps geométricos que añade selección basada en quadtree para lograr una mayor adaptabilidad alrededor de la posición de la cámara. La idea clave: en lugar de usar anillos concéntricos fijos, emplear un quadtree para seleccionar parcelas de terreno con distintas resoluciones. Esto gestiona mejor que los clipmaps puros los terrenos irregulares, donde algunas zonas necesitan más detalle que otras. Puede implementarse en WebGL 2 con un pequeño recorrido del quadtree en la CPU.

Splatting gaussiano 3D y renderizado neuronal

«Splatting gaussiano 3D para el renderizado en tiempo real de campos de radiancia» -- Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). Página del proyecto. El artículo que desencadenó la revolución del splatting gaussiano. Una escena se representa mediante millones de gaussianas 3D, cada una con posición, covarianza (forma), opacidad y coeficientes de color de armónicos esféricos. El renderizado ordena los splats por profundidad y los rasteriza como gaussianas 2D. Este enfoque es entre 100 y 1000 veces más rápido de entrenar que los NeRF y renderiza en tiempo real. Existen múltiples implementaciones para WebGL y WebGPU. En nuestra plataforma, esto permite a los creadores capturar objetos reales con fotos tomadas con el teléfono y colocarlos en el mundo del navegador.

«NeRF: Representación de escenas como campos neuronales de radiancia para la síntesis de vistas» -- Mildenhall et al. (ECCV 2020). Página del proyecto. El artículo fundacional sobre representación neuronal de escenas. Una red neuronal asigna color y densidad a coordenadas 3D, lo que permite sintetizar nuevas vistas fotorrealistas a partir de un conjunto de fotografías de entrada. Aunque los NeRF son demasiado costosos para renderizarlos directamente en un navegador (requieren evaluar la red por cada píxel), el pipeline de extracción de NeRF a malla —entrenar un NeRF y después ejecutar marching cubes sobre el campo de densidad— produce mallas texturizadas de alta calidad a partir de fotografías.

«Primitivas gráficas neuronales instantáneas con codificación hash multirresolución» -- Müller, Evans, Schied, Keller (SIGGRAPH 2022). Página del proyecto. Redujo el entrenamiento de NeRF de horas a segundos mediante una tabla hash multirresolución para la codificación espacial. Esto hizo que los NeRF fueran prácticos para entornos de producción. La técnica de codificación hash también puede aplicarse a otros datos espaciales de un mundo en el navegador, como consultas rápidas en grandes conjuntos de datos 3D.

«Neuralangelo: Reconstrucción neuronal de superficies de alta fidelidad» -- Li et al. (CVPR 2023). Página del proyecto. Extrae mallas triangulares de alta calidad de representaciones neuronales mediante codificación hash multirresolución y gradientes numéricos para estimar la SDF (función de distancia con signo). Las mallas resultantes pueden utilizarse directamente en motores 3D para navegadores. En nuestro pipeline de recursos, Neuralangelo —o herramientas similares como NeuS2— puede convertir capturas NeRF en archivos GLB listos para la web, con geometría limpia y texturas prehorneadas.

Redes multijugador y sincronización de estado

«Gestión de relevancia en juegos multijugador masivos en línea» -- Boulanger, Kienzle, Verbrugge (2006). DOI. Un estudio exhaustivo de las técnicas de gestión de áreas de interés (AOI) para MMO. Abarca enfoques basados en cuadrículas, en auras e híbridos para filtrar las actualizaciones de red según su relevancia espacial. El enfoque basado en cuadrículas —que se corresponde con nuestro sistema de chunks— es el más eficiente para mundos con densidad uniforme. El enfoque basado en auras —un radio de influencia por entidad— funciona mejor con densidades variables. Nuestra recomendación de usar AOI basadas en chunks, con frecuencias de actualización determinadas por prioridad dentro del AOI, parte de esta investigación.

«Navegación por estima: ocultación de la latencia en juegos en red» -- Pantel y Wolf (2002). DOI. Formaliza la navegación por estima —predecir las posiciones de las entidades a partir de la última velocidad conocida— para juegos en red. El artículo cuantifica la contrapartida: unos umbrales de predicción más altos reducen el ancho de banda, pero aumentan el error de posición visible durante las correcciones. En juegos de navegador con una latencia de entre 50 y 200 ms, un umbral de predicción de entre 0,5 y 1,0 metros mantiene imperceptibles las correcciones a la vez que reduce entre un 60 % y un 80 % el ancho de banda destinado a actualizar posiciones.

«Tipos de datos replicados sin conflictos» -- Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. El artículo fundacional sobre CRDT. Define CRDT basados en estado y basados en operaciones que convergen sin coordinación. Para nuestro sistema de edición de mundos, los CRDT relevantes son: LWW-Register (registro en el que prevalece la última escritura) para propiedades de objetos con un único valor (posición, rotación, color) y OR-Set (conjunto de adición observada) para la colección de objetos de un chunk, que gestiona adiciones y eliminaciones simultáneas sin conflictos. Yjs los implementa de forma eficiente en JavaScript.

«Time Warp: Un mecanismo para la simulación distribuida» -- Jefferson (1985). DOI. El artículo original sobre simulación distribuida optimista. Aunque Time Warp es demasiado complejo para un juego de navegador, su idea central —procesar eventos de forma optimista y revertirlos si llega un conflicto desde otro nodo— constituye la base de la predicción moderna en el cliente con reconciliación del servidor. Así funcionan todos los juegos multijugador con buena respuesta: el cliente predice localmente, envía acciones al servidor y corrige el estado si el servidor discrepa.

«El modelo de red del motor TRIBES» -- Frohnmayer y Gift (GDC 1999). Una de las primeras descripciones prácticas de redes cliente-servidor para juegos, con gestión de relevancia, actualizaciones de estado priorizadas y asignación de ancho de banda. El concepto de «gestor de réplicas» —el servidor mantiene para cada cliente una vista de lo que este conoce y solo envía las diferencias respecto a esa vista— es exactamente lo que implementa nuestra arquitectura de Durable Objects basada en chunks. Esta charla de la GDC es el antecedente intelectual de la mayoría de los sistemas de red modernos para juegos.

«Redes multijugador de Source» -- Valve (2009). Documentación para desarrolladores. La documentación de Valve sobre el modelo de red del motor Source, utilizado en Half-Life 2, CS:GO y Team Fortress 2. Abarca la predicción en el cliente, la interpolación de entidades, la compensación de latencia y el sistema de «instantáneas», en el que el servidor envía el estado completo del mundo a intervalos regulares mientras el cliente interpola entre instantáneas. Es el referente de excelencia para redes con servidor autoritativo y puede aplicarse directamente a nuestra arquitectura.

Generación procedural

«Síntesis de modelos: Un algoritmo general de modelado procedural» -- Merrell (2007). DOI. Uno de los precursores de Wave Function Collapse. Genera estructuras 3D a partir de modelos de ejemplo mediante la propagación de restricciones locales. El algoritmo garantiza la coherencia global colapsando iterativamente las celdas con menos posibilidades —la heurística de entropía mínima—. Así es como Townscaper y otros generadores similares producen estructuras coherentes a partir de entradas sencillas del usuario.

«WaveFunctionCollapse» -- Maxim Gumin (2016). GitHub. No es un artículo tradicional, sino un proyecto seminal de código abierto con documentación exhaustiva. El algoritmo toma una pequeña imagen de ejemplo o un conjunto de teselas y genera resultados de mayor tamaño localmente similares a la entrada. En un mundo de creadores, WFC puede generar distribuciones de edificios, redes de carreteras, mapas de mazmorras y detalles del terreno a partir de un pequeño conjunto de reglas definidas por el creador. Existen múltiples implementaciones en JavaScript.

«Wave Function Collapse es resolución de restricciones en la práctica» -- Karth y Smith (FDG 2017). DOI. Un análisis académico de WFC que aclara su relación con la satisfacción de restricciones y muestra cómo analizarlo y ampliarlo. Es relevante para entender las limitaciones de WFC —puede atascarse y necesitar retroceso— y cómo diseñar conjuntos de teselas que eviten estos problemas.

«El teorema de superposición y sus implicaciones para la generación procedural de contenido de juegos» -- Sandhu et al. (2022). Explora el uso de conceptos de superposición inspirados en la mecánica cuántica para la generación procedural de contenido. Aunque es especulativo, el marco matemático para mantener múltiples estados posibles antes de «colapsar» hasta una configuración final es precisamente la forma en que funciona WFC y podría servir de base para sistemas de generación más sofisticados.

Técnicas de renderizado en tiempo real

«Renderizado en tiempo real» -- Akenine-Möller, Haines, Hoffman (4.ª edición, 2018). El manual de referencia. El capítulo 19 (Estructuras de aceleración), el capítulo 20 (Sombreado eficiente) y el capítulo 21 (Realidad virtual y aumentada) son especialmente relevantes. Los algoritmos de descarte por frustum, descarte por oclusión y LOD descritos aquí son los que implementan Three.js, Babylon.js y todos los motores de juegos. No es un artículo, sino la referencia definitiva.

«Estudio sobre el prehorneado de campos neuronales de radiancia para la síntesis de vistas en tiempo real» -- Reiser et al. (2023). DOI. Estudia métodos para convertir NeRF en formatos que puedan renderizarse en tiempo real, como mallas, texturas y cuadrículas dispersas de vóxeles. Es directamente relevante para nuestro pipeline de recursos, donde las capturas neuronales procesadas en el servidor deben producir resultados renderizables en el navegador.

«Emparejamiento de características en línea, escalable y preciso, mediante splatting gaussiano 3D» -- Varios grupos (2024-2025). Múltiples artículos recientes exploran la edición, la composición y las escenas dinámicas con splats gaussianos. Es relevante porque los mundos de creadores necesitan combinar varias escenas de splats —los objetos capturados por cada creador— en una única escena coherente. Los métodos de edición de splats —recoloración, deformación y composición— son áreas activas de investigación.

«Trazado eficiente de rayos en espacio de pantalla mediante GPU» -- McGuire y Mara (JCGT 2014). DOI. El artículo en el que se basan las reflexiones en espacio de pantalla utilizadas en nuestra sección sobre renderizado del agua. Traza rayos a través del búfer de profundidad para obtener reflexiones aproximadas sin el coste de un trazado de rayos completo. La variante de «trazado jerárquico» —que utiliza un mipmap de profundidad mín.-máx.— se ejecuta eficientemente en WebGL 2.

«Simulación del agua oceánica» -- Jerry Tessendorf (2001). PDF. El artículo fundacional sobre la simulación oceánica basada en FFT. Describe el espectro de Phillips —un modelo estadístico de las olas oceánicas— y cómo transformarlo en un mapa de desplazamiento espacial mediante una FFT inversa. Se utiliza en todos los grandes juegos con océanos realistas, como Sea of Thieves, Assassin's Creed y Uncharted. El cálculo de la FFT se adapta perfectamente a los shaders de cómputo de WebGPU.

«Dispersión atmosférica precalculada» -- Bruneton y Neyret (EGSR 2008). DOI. El artículo en el que se basa el renderizado de cielos físicamente preciso. Precalcula la dispersión atmosférica en tablas de consulta que un shader de fragmentos muestrea en tiempo real. Produce desde primeros principios colores correctos del cielo, perspectiva aérea —los objetos lejanos parecen azulados o brumosos— y colores de amaneceres y atardeceres. Las tablas precalculadas son pequeñas —unos pocos cientos de KB— y el shader de ejecución es ligero. Tanto el shader Sky de Three.js como el cielo procedural de Babylon.js son versiones simplificadas de este enfoque.

«Volúmenes de oclusión ambiental» -- McGuire (HPG 2010) y «Oscurecimiento ambiental escalable» -- McGuire, Mara, Luebke (HPG 2012). PDF. Los artículos en los que se basan las implementaciones modernas de SSAO. SAO es la variante implementada con mayor frecuencia en motores 3D para navegadores porque es eficiente —una muestra del búfer de profundidad por píxel— y produce sombras de contacto plausibles. El algoritmo muestrea el búfer de profundidad alrededor de cada píxel para estimar hasta qué punto está «ocluido» por la geometría cercana. Tanto Three.js como Babylon.js implementan SSAO derivado de SAO.

Renderizado y animación de multitudes

«Renderizado de multitudes mediante GPU» -- Dudash (2007) y posteriores presentaciones de GDC/SIGGRAPH sobre el renderizado instanciado de multitudes. La técnica principal consiste en prehornear los fotogramas de animación esquelética en texturas —Vertex Animation Textures— y después renderizar las multitudes como mallas instanciadas, donde cada instancia lee las transformaciones de sus huesos desde la textura de animación según su fotograma actual. Esto desacopla la evaluación de animaciones de las llamadas de dibujo, lo que permite que una única llamada de dibujo instanciada renderice cientos de personajes con animaciones distintas.

«Dinámica basada en posiciones» -- Müller et al. (2007). DOI. El artículo fundacional sobre PBD, que es la técnica con la que los motores de juegos modernos simulan telas, cabello y cuerpos blandos. Rapier —nuestro motor de física Wasm recomendado— utiliza solucionadores derivados de PBD. Para la personalización de avatares —capas, cabello suelto y ropa holgada—, PBD proporciona una simulación con buena respuesta a las frecuencias de fotogramas de los juegos. La implementación en Wasm evita ejecutarla en el hilo principal de JavaScript. «FABRIK: un solucionador rápido e iterativo para el problema de la cinemática inversa» -- Aristidou y Lasenby (2011). DOI. El artículo en el que se basa el solucionador de cinemática inversa recomendado en nuestra sección sobre avatares. FABRIK funciona alternando recorridos desde el efector final hasta la raíz y desde la raíz hasta el efector final, y converge en 3-5 iteraciones. Es más rápido que la cinemática inversa basada en jacobianos, gestiona las restricciones articulares de forma natural y es fácil de implementar (unas 50 líneas de código para el solucionador básico). Tanto las implementaciones de cinemática inversa de Three.js como las de Babylon.js derivan de FABRIK.

Mundos virtuales y entornos colaborativos

«Juegos multijugador masivos en línea: un estudio del estado del arte» -- Yahyavi y Kemme (2013). DOI. Estudio exhaustivo de la arquitectura de los MMO que abarca modelos cliente-servidor, enfoques entre pares, gestión de interés, modelos de consistencia, técnicas de escalabilidad y prevención de trampas. La taxonomía de los modelos de consistencia (estricta, eventual y causal) se corresponde con nuestro enfoque basado en CRDT (consistencia eventual con orden causal mediante relojes vectoriales).

«Una arquitectura distribuida para aplicaciones interactivas multijugador en Internet» -- Diot y Gautier (1999). DOI. Investigación pionera sobre entornos virtuales distribuidos que identificó la tensión fundamental: la consistencia estricta requiere coordinación (lo que añade latencia), mientras que la consistencia débil permite una mayor capacidad de respuesta, pero conlleva el riesgo de inconsistencias visibles. El artículo propone el «retraso local» (demorar ligeramente la visualización local para dar tiempo a que lleguen las actualizaciones remotas) como punto intermedio. Para las ediciones del mundo (como colocar objetos), un retraso local de 100-200 ms resulta imperceptible y da tiempo al servidor para validarlas.

«La cuadrícula de Second Life: la arquitectura de un mundo virtual de código abierto casi contemporáneo» -- Documentación técnica de Linden Lab e ingeniería inversa de la comunidad. Aunque no se trata de un único artículo, el análisis técnico de la arquitectura de Second Life está ampliamente documentado. Las conclusiones clave: cada región de 256x256 m se ejecuta en una instancia de servidor dedicada. Los objetos se almacenan como un árbol de «primitivas» (formas básicas con transformaciones, texturas y scripts). El visor transmite bajo demanda las descripciones y texturas de los objetos. Este modelo basado en parcelas y con persistencia por objeto es la arquitectura existente más parecida a la que estamos construyendo, y los más de 20 años de funcionamiento de Second Life demuestran que puede escalar.

Gráficos web y rendimiento del navegador

«WebGPU: una API de gráficos de alto rendimiento para la web» -- Grupo de Trabajo GPU for the Web del W3C (2023-en curso). Especificación. La especificación formal de WebGPU. No es un artículo de investigación, sino el documento técnico definitivo para la programación de GPU en navegadores. La especificación de los shaders de cómputo (Sección 23) es especialmente relevante para la generación de terrenos, la distribución de vegetación y los sistemas de partículas descritos a lo largo de esta guía.

«WebAssembly: un marco para ejecutar código compilado en el navegador» -- Haas et al. (PLDI 2017). DOI. El artículo original sobre WebAssembly elaborado por los proveedores de navegadores. Demuestra que Wasm logra un rendimiento que se mantiene dentro de un factor de 2 respecto al código nativo en cargas de trabajo intensivas en cómputo. Esto respalda nuestra recomendación de usar motores de física compilados a Wasm (Rapier, Havok) para mundos abiertos en el navegador. El análisis de rendimiento del artículo muestra que la sobrecarga procede principalmente de la comprobación de límites y las llamadas indirectas a funciones, no del propio modelo de compilación.

«No tan rápido: análisis del rendimiento de WebAssembly frente al código nativo» -- Jangda et al. (USENIX ATC 2019). PDF. Una evaluación comparativa rigurosa del rendimiento de Wasm frente al código nativo. Determina que Wasm se ejecuta de media entre 1,45 y 1,55 veces más lento que C nativo en el conjunto de pruebas SPEC CPU. En el caso concreto de la física para videojuegos (con muchos cálculos de coma flotante y pocas llamadas al sistema), la sobrecarga se sitúa en el extremo inferior (~1,3 veces). Esto confirma que la física en Wasm dentro de un navegador es viable para cargas de trabajo de juegos en tiempo real.

«Acelerando la web con WebAssembly» -- Rossberg et al. (2018). DOI. Describe los fundamentos del diseño y la semántica formal de WebAssembly. Es especialmente relevante el análisis de las garantías de seguridad de memoria (Sección 3), que explica por qué los módulos Wasm pueden compartir de forma segura una pestaña del navegador con JavaScript sin los riesgos de seguridad de los complementos nativos. Esto es lo que permite ejecutar de forma segura en un navegador motores de física, que tradicionalmente eran bibliotecas de C++.

Generación de contenido mediante IA

«Generación de texto a 3D con difusión bidireccional mediante conocimiento previo 2D y 3D» -- Varios grupos (2023-2025). Diversos artículos recientes (DreamFusion, Magic3D, ProlificDreamer, MVDream, Zero-1-to-3++) exploran la generación de recursos 3D a partir de instrucciones de texto mediante el uso de modelos de difusión 2D como conocimiento previo para la optimización 3D. La calidad ha mejorado drásticamente desde principios de 2023 hasta 2025, pasando de formas amorfas a mallas detalladas y texturizadas. Para nuestra plataforma, estos modelos (ejecutados en GPU del lado del servidor) constituyen el paso de «generación mediante IA» del flujo de trabajo de recursos para creadores.

«DreamFusion: de texto a 3D mediante difusión 2D» -- Poole et al. (ICLR 2023). Página del proyecto. El artículo fundacional sobre Score Distillation Sampling (SDS), que utiliza un modelo de difusión 2D preentrenado para guiar la optimización 3D. La idea clave: no hacen falta datos de entrenamiento 3D si se puede evaluar, mediante un modelo 2D existente, si las vistas renderizadas de un objeto 3D coinciden con una instrucción de texto. Esto abrió la puerta a la generación de texto a 3D y constituye la base de trabajos posteriores (Magic3D, ProlificDreamer) que mejoraron la calidad y la velocidad.

«LRM: gran modelo de reconstrucción de una sola imagen a 3D» -- Hong et al. (ICLR 2024). Página del proyecto. Reconstruye un modelo 3D a partir de una sola imagen en 5 segundos con una única GPU. El modelo produce una representación similar a NeRF que puede convertirse en una malla. Para un mundo creado por usuarios, esto significa que un creador podría fotografiar cualquier objeto del mundo real y obtener un modelo 3D en cuestión de segundos. Su velocidad lo hace viable como herramienta interactiva en lugar de como proceso por lotes.

«Generación procedimental de contenido mediante aprendizaje automático (PCGML)» -- Summerville et al. (2018). DOI. Un estudio sobre el uso del aprendizaje automático para la generación procedimental de contenido en videojuegos. Abarca la generación de niveles, objetos, narrativas y mundos. Resulta especialmente relevante el análisis de la «generación controlable», en la que los diseñadores establecen parámetros de alto nivel y el modelo de aprendizaje automático completa los detalles. Este es el paradigma de la creación de mundos asistida por IA: los creadores definen la intención («convierte esta zona en un bosque tenebroso») y la IA completa la geometría, las texturas y la población.

Cómo se relacionan estos artículos con nuestra arquitectura

La investigación se corresponde con nuestra arquitectura por capas:

Flujo de trabajo del terreno: El ruido Perlin/simplex (Perlin 1985, 2001) genera el mapa de alturas base. La erosión hidráulica (Mei et al. 2007) añade realismo geológico. Los clipmaps geométricos (Losasso y Hoppe 2004) o CDLOD (Strugar 2014) renderizan el terreno de manera eficiente en el navegador. La dispersión atmosférica (Bruneton y Neyret 2008) hace que el terreno distante se vea correctamente.

Flujo de trabajo de recursos: Los sistemas de texto a 3D (DreamFusion et al.) y de imagen a 3D (LRM) generan recursos en el servidor. El splatting gaussiano (Kerbl et al. 2023) permite capturas fotogramétricas. Neuralangelo (Li et al. 2023) extrae mallas limpias de capturas neuronales. Todas las salidas se procesan y convierten en archivos GLB/KTX2 listos para el navegador.

Renderizado: SSAO (McGuire 2012) añade profundidad. Los reflejos en espacio de pantalla (McGuire y Mara 2014) se encargan del agua. El océano por FFT (Tessendorf 2001) simula el agua. Las texturas de animación de vértices (Dudash 2007) renderizan multitudes. FABRIK (Aristidou y Lasenby 2011) controla la cinemática inversa de los personajes.

Red: La gestión de interés (Boulanger et al. 2006) filtra las actualizaciones según su relevancia espacial. La navegación por estima (Pantel y Wolf 2002) reduce el ancho de banda. Los CRDT (Shapiro et al. 2011) gestionan la edición colaborativa. La predicción del cliente con reconciliación del servidor (Jefferson 1985, redes de Valve Source) ofrece una respuesta inmediata.

Generación del mundo: WFC (Gumin 2016, Karth y Smith 2017) genera estructuras y distribuciones. PCGML (Summerville et al. 2018) proporciona el marco para la generación asistida por IA, en la que los creadores definen la intención y los modelos completan los detalles.

La investigación está consolidada. La mayoría de estas técnicas llevan años utilizándose en juegos publicados. La innovación al trasladarlas a un navegador no está en los algoritmos, sino en la ingeniería necesaria para hacer que funcionen dentro de las limitaciones de memoria, GPU y red del navegador, que es lo que aborda el resto de esta guía.

Lecturas adicionales

• Tecnologías para juegos web en 2026 explica los fundamentos de WebGL, WebGPU y WebAssembly
• Comparativa de motores para juegos web compara motores para su distribución en el navegador
• Informe técnico sobre Three.js + USDC acerca de la carga de recursos 3D en el navegador
• Modelos avanzados de IA generativa de código abierto para el flujo de trabajo de generación mediante IA
• Diseño de juegos cooperativos sobre patrones de diseño multijugador que mantienen el interés de los jugadores
• Generación de paisajes para mundos abiertos en el navegador — renderizado de terreno, erosión y vegetación
• Fundamentos del multijugador con WebSocket — primeros pasos con las redes multijugador en el navegador
• Primeros pasos con WebGPU — la API de renderizado para la próxima generación de experiencias 3D en el navegador
• Carga de recursos mediante streaming — patrones de carga progresiva para grandes mundos 3D

Pruébalo ahora mismoPrueba ahora mismo un mundo abierto en tu navegador

Escribe una frase y obtén un mundo 3D explorable.

Créalo gratis →Es gratis, funciona en tu navegador, nada que instalar.