Cómo construir un mundo abierto en el navegador, parte 3: Las pruebas poco vistosas que nos salvaron

Por Oleg Sidorkin, CTO y cofundador de Cinevva

¿Es tu primera vez aquí? Consulta la guía de la serie. Explica qué es una prueba técnica y enlaza todas las partes.

Esta parte tiene menos capturas de pantalla llamativas y más garantías arquitectónicas.

Después de las pruebas 1 y 2, realizamos tres comprobaciones de riesgo que parecían pequeñas, pero tuvieron un impacto a nivel de producto.

La primera fue la distribución de difusiones con Durable Objects. Probamos la distribución de posiciones entre múltiples clientes con frecuencias de actualización similares a las de un juego y medimos la distribución de la latencia, el uso de CPU por actualización y la integridad de la entrega. Si hubiera fallado, habríamos adoptado desde el principio una arquitectura fragmentada, en lugar de asignar cada isla a una única instancia.

La segunda fue la validación de las limitaciones móviles. No se trataba de un ajuste predefinido para escritorio rebautizado como móvil, sino de un perfil explícito de bajo coste basado en el mismo terreno de referencia.

Abrir el perfil móvil en una pestaña nueva ↗ · Ver el código fuente

Redujimos la densidad de segmentos, el número de objetos, la presión sobre la resolución de renderizado y el alcance de la niebla. La pregunta era sencilla: ¿puede este mundo seguir siendo legible y ágil bajo las limitaciones propias de los dispositivos móviles sin tener que reescribir todo el renderizador?

La tercera fue la fiabilidad de la generación de comportamientos para los flujos de trabajo de los creadores. Evaluamos la tasa de JSON válido, la corrección semántica respecto a las primitivas esperadas y la latencia de respuesta. Si hubiera fallado, habríamos pasado a una creación de comportamientos estrictamente basada en formularios.

La idea clave de este capítulo es que estas pruebas poco vistosas cambiaron la arquitectura más rápido que las pruebas visuales. Establecieron límites firmes para la topología de red, las promesas en móviles y la experiencia de usuario de las herramientas.

En la parte 4 volvemos al trabajo visible sobre el terreno y probamos el comportamiento de la carga progresiva durante el movimiento, no solo mediante capturas de pantalla de cargas estáticas.

Tecnología mencionada en este capítulo

Cloudflare Durable Objects. Instancias sin servidor con estado, desplegadas en el edge, con persistencia integrada y compatibilidad con WebSocket. Cada Durable Object mantiene el estado autoritativo de un fragmento —o chunk— del mundo. Los jugadores se conectan mediante WebSocket y reciben difusiones de posición de otros jugadores del mismo fragmento. Cuando un jugador se desplaza a un chunk adyacente, se conecta al Durable Object de ese chunk. Los Durable Objects guardan automáticamente el estado en disco y pueden escalar hasta miles de instancias simultáneas. Consulta la documentación de Cloudflare Durable Objects y nuestra guía de tecnología 3D para navegador sobre redes multijugador.

Fragmentación espacial. División del mundo entre instancias de servidor según la región geográfica. Cada fragmento controla un área rectangular de la cuadrícula del mundo. A medida que cambia la densidad de jugadores, los fragmentos pueden dividirse o fusionarse. Los jugadores próximos al límite de un fragmento ven el contenido de ambos mediante consultas de visibilidad entre fragmentos. Así es como EVE Online gestiona a miles de jugadores en un único universo.

Distribución de difusiones mediante WebSocket. Distribución de actualizaciones de posición en tiempo real desde un servidor a numerosos clientes conectados. El ancho de banda descendente por cliente aumenta linealmente con la cantidad de jugadores visibles:

$$B_{\text{client}}=N_{\text{visible}}\times b_{\text{player}}$$

Con frecuencias de actualización propias de un juego (20-30 Hz), cada jugador genera $b_{\text{player}}\approx 800$ bytes/segundo de datos de posición, por lo que tener 200 jugadores visibles consume $200\times 800=160$ KB/s por cliente. El coste para el servidor de un enfoque ingenuo de todos contra todos es aún peor, pues crece como $N^2$. Precisamente por eso, el filtrado por relevancia —la gestión espacial de áreas de interés— limita $N_{\text{visible}}$ antes de enviar los datos a cada conexión dentro del tiempo disponible por actualización. Consulta nuestra guía sobre redes para conocer las ventajas y desventajas de la compresión delta y de las distintas frecuencias de actualización.

Limitaciones del renderizado móvil. Las GPU móviles ofrecen entre 1/5 y 1/10 del rendimiento de las GPU de escritorio, tienen un límite de memoria de aproximadamente 1 GB —frente a 2-4 GB en equipos de escritorio— y reducen su rendimiento por temperatura bajo cargas prolongadas. Un perfil de calidad móvil reduce la densidad de segmentos, el número de objetos, la resolución de renderizado, la distancia de dibujado y la calidad de las sombras. El objetivo no es igualar la calidad de escritorio, sino mantener la legibilidad y la capacidad de respuesta. Consulta las cifras de rendimiento 3D en el navegador para ver pruebas de rendimiento con GPU reales.

---

Parte 3 de 12.
Anterior: Parte 2 - La física en un worker y el temor al retardo de entrada
Siguiente: Parte 4 - Carga progresiva antes que terrenos sofisticados
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide