Construir un mundo abierto en el navegador, parte 1: Empezamos intentando romperlo
Por Oleg Sidorkin, CTO y cofundador de Cinevva
¿Acabas de llegar? Consulta la guía de la serie. Explica qué es un spike y enlaza todas las partes.
Estamos construyendo un mundo abierto multijugador que se ejecuta íntegramente en el navegador. Sin instalación, sin tienda de aplicaciones, solo una URL. El mayor riesgo inicial era evidente: ¿puede un navegador renderizar un mundo 3D persistente con una tasa de fotogramas jugable y, al mismo tiempo, dejar margen para la jugabilidad, la física y la red?
La mayoría de los proyectos de mundo abierto fracasan en un orden predecible. Primero tienes un buen concepto. Después, una escena bonita. Luego te das cuenta de que ya has agotado el presupuesto por fotograma antes de que exista la jugabilidad.
Queríamos resolver la cuestión del presupuesto de renderizado antes de invertir en cualquier otra cosa. Por eso, el Spike 1 se saltó el tráiler vistoso y fue directamente a las mediciones.
Abrir el Spike 1 en una pestaña nueva ↗ · Ver el código fuente
La configuración era sencilla a propósito. Una malla de terreno de 512 metros, altura procedural generada mediante varias capas de ruido sinusoidal con atenuación hacia los bordes de la isla, un plano de agua, niebla atmosférica y 500 objetos instanciados. Usamos WebGL puro con Three.js, mapeo de tonos ACES y sin sombras.
No nos importaba su aspecto. Nos importaba que la escena se mantuviera estable al mover la cámara por ella.
De este spike surgieron dos conclusiones que dieron forma a todo el proyecto.
En primer lugar, confirmamos que teníamos un margen real en equipos de escritorio si manteníamos una primera implementación disciplinada. Eso nos dio confianza para intentar más adelante una arquitectura de terreno más compleja.
En segundo lugar, establecimos un contrato de referencia. Cada spike posterior tenía que explicar su coste en relación con esta escena. Si una funcionalidad se veía bien, pero costaba demasiado, no avanzaba a la siguiente fase.
Esa disciplina basada en una referencia se volvió crucial más adelante, cuando nos encontramos con artefactos en las uniones, transiciones entre distintos niveles de LOD y mallado controlado por cómputo. Sin una referencia estable, todos los errores parecen más grandes de lo que son.
En la parte 2 pasamos del renderizado a la respuesta de los controles. La física en un worker suena muy bien en los documentos de arquitectura. Pero solo importa si el personaje sigue respondiendo de inmediato al pulsar una tecla.
Tecnología mencionada en este capítulo
Terreno basado en mapas de altura. Una cuadrícula 2D en la que cada celda almacena un único valor de elevación. La GPU desplaza una malla plana en el shader de vértices para crear la superficie del terreno. Los mapas de altura son compactos (un chunk de 65x65 ocupa unos 8 KB a 16 bits), están bien adaptados a la GPU y se renderizan con rapidez. Su limitación es que no pueden representar cuevas, salientes ni ninguna superficie que se pliegue sobre sí misma. Para obtener más información sobre las limitaciones de los mapas de altura y las alternativas posteriores, consulta nuestra guía de generación de paisajes.
Three.js. La biblioteca de renderizado que usamos durante todo este proyecto. Three.js abstrae WebGL 2 —y, posteriormente, WebGPU— mediante un grafo de escena con cámaras, luces, materiales y objetos geométricos. Proporciona InstancedMesh para renderizar muchas copias de una misma geometría en una sola llamada de dibujo, además de descarte por frustum, materiales PBR y posprocesamiento. Consulta Three.js en GitHub. Para saber cómo encaja Three.js en la pila tecnológica de un mundo abierto para navegador, consulta nuestra guía de tecnologías 3D para el navegador.
InstancedMesh. Una funcionalidad de Three.js que renderiza N copias de una misma geometría con una sola llamada de dibujo, cada una con una posición, rotación y escala diferentes. Las transformaciones de cada instancia se almacenan en un búfer de atributos matriciales. Así renderizamos 500 objetos en el Spike 1 sin realizar 500 llamadas de dibujo independientes. Para vegetación a gran escala, el descarte de instancias controlado por la GPU lleva este enfoque aún más lejos. Consulta nuestra guía de paisajes sobre el descarte de vegetación mediante la GPU.
Presupuesto por fotograma. A 60 fps, cada fotograma dispone de
Parte 1 de 12.
Siguiente: Parte 2: Física en un worker y el temor al retardo de entrada
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide