Cómo Highstreet Market escaló un MMO de VR con ECS para Unity

Highstreet: Calamity es una porción a escala de ciudad del MMORPG de próxima generación de Highstreet Market. El equipo lo lanzó a la comunidad de jugadores para probar características centrales como el combate y la progresión.

En esta etapa, el equipo se centra en escalar la experiencia multijugador. Durante el desarrollo, encontraron cuellos de botella técnicos, pero a través de un perfilado y una iteración cuidadosos, identificaron y abordaron los problemas raíz. Así es como lo hicieron.

Highstreet: Calamity: Un caso de estudio de Unity

¿Cómo escala un estudio el desarrollo multijugador mientras supera desafíos técnicos?

Cuando estaban comenzando a configurar su juego en red, el equipo enfrentó dos desafíos importantes: ineficiencias de computación y renderizado.

“En el lado de la computación, nuestro mayor desafío fue manejar la computación de manera eficiente. Esto es especialmente cierto para nuestro servidor, que tiene la tarea de simular el mundo,” dice Jack Qiao, CTO de Highstreet. “A medida que agregamos más jugadores y entidades de red, el servidor luchó por procesarlos todos de manera eficiente.”

En el lado de la representación, construir grandes mundos inmersivos en VR es difícil. “VR exige un entorno atractivo con muchos objetos y puntos de interés para que los jugadores exploren,” explica Qiao. “Pero el hardware de VR independiente tiene un poder de GPU limitado en comparación con las GPU modernas de PC, lo que restringe lo que podemos renderizar.”

Para mantener la calidad, el equipo diseñó cuidadosamente las escenas para que se vieran bien desde cada ángulo mientras equilibraban los límites de rendimiento inherentes a VR.

Los resultados

Alcanzó 72 fps en las áreas de juego más optimizadas

Redujo el número de llamadas de dibujo del Scriptable Render Pipeline (SRP) de 80 a cinco

Disminuyó el número de triángulos en una sola malla de dos millones a 500,000

Adopción de ECS para Unity para eficiencia en la red

El equipo primero construyó un servidor personalizado sobre la capa de transporte de Mirror para manejar el flujo de datos y la lógica del juego. “En ese momento, la mayoría de las herramientas de red estaban diseñadas para títulos móviles casuales, no para MMOs a gran escala, así que tuvimos que crear la nuestra,” dice Omar Sleam, arquitecto técnico principal de Highstreet.

Cuando Unity introdujo Netcode for Entities – un marco listo para producción construido para el rendimiento y juegos a gran escala – el equipo vio una oportunidad para hacer la transición al Sistema de Componentes de Entidad (ECS) de Unity y Netcode for Entities. Diseñado con la escalabilidad en mente, el marco introdujo el fragmentado, que divide los datos complejos del juego en unidades más pequeñas y manejables – algo que el equipo consideró esencial para su MMO.

“Con Netcode for Entities, los datos solo se envían a los jugadores dentro del rango en lugar de transmitir a todo el servidor,” explica Sleam. “También es multihilo, lo que hace que las operaciones del servidor sean mucho más eficientes.”

Más allá de la red, el equipo también desarrolló un sistema de árbol de comportamiento construido completamente con ECS para Unity. Las iteraciones anteriores dificultaron la implementación de características genéricas, particularmente aquellas relacionadas con el control de flujo. El ECS personalizado para el árbol de comportamiento basado en Unity resolvió esta limitación, proporcionando herramientas flexibles y reutilizables sin comprometer el rendimiento.

El equipo diseñó el sistema para operar sin problemas en un entorno en red, dando la flexibilidad de ejecutar árboles de comportamiento en el servidor, el cliente o ambos. Esto les permitió descargar comportamientos no críticos al cliente, mejorando el rendimiento mientras mantenían el control centralizado para la lógica central del juego.

Para gestionar la estructura basada en sesiones del juego, el equipo se apoyó en el ecosistema de servicios multijugador de Unity. Multiplay Hosting permitió la asignación dinámica de servidores, lo cual era ideal para la naturaleza basada en sesiones del juego. “La automatización redujo nuestra carga de DevOps y nos permitió centrarnos en construir el juego en sí”, dice Sleam. Matchmaker se utilizó para agrupar jugadores en función de varios factores como configuraciones y ubicación, ayudando a garantizar partidas equilibradas y de baja latencia.

Unity Lobby impulsó el sistema de grupos para que los jugadores pudieran formar y gestionar grupos antes de unirse a una sesión de juego. Friends se integró con Lobby para mantener grupos a través de diferentes servidores, permitiendo a los jugadores mantenerse conectados con un esfuerzo de implementación mínimo y sin requerir un backend personalizado.

Juntos, estas herramientas proporcionaron una columna vertebral multijugador completa, cubriendo alojamiento, emparejamiento, gestión de grupos y sistemas sociales, mientras mantenían la implementación ligera, escalable y optimizada para un juego de alto rendimiento.

Mejorando la modularidad con ECS para Unity

Si bien el equipo experimentó una curva de aprendizaje pronunciada durante su transición de un diseño basado en GameObject a ECS para Unity, la productividad mejoró significativamente una vez que se integraron.

“ECS para Unity redujo mucho la sobrecarga, en parte debido a su arquitectura y en parte porque cambiamos a un enfoque de diseño de arriba hacia abajo”, dice Qiao. “A diferencia de los GameObjects, que a menudo llevaban a una lógica duplicada a menos que se arquitecturaran cuidadosamente, ECS para Unity imponía un diseño modular basado en componentes. Esto promovió naturalmente sistemas más limpios y mantenibles.”

El equipo compartió que uno de los mayores beneficios de ECS para Unity es lo fácil que fue manejar los cambios en el diseño del juego. “En el antiguo sistema, los cambios a menudo requerían tocar múltiples scripts de MonoBehaviour. Con ECS para Unity, muchos cambios se pueden realizar simplemente agregando o eliminando componentes, ya que los comportamientos son impulsados por sistemas vinculados a esos componentes”, dice Qiao. “En general, la modificabilidad y escalabilidad han mejorado enormemente con ECS para Unity, y ha hecho que nuestro pipeline de desarrollo sea mucho más eficiente.”

El equipo también abordó un gran desafío en torno a la arquitectura del juego. A diferencia del software tradicional, la lógica del juego depende no solo del código, sino también de dónde vive ese código. Por ejemplo, adjuntar un script de rotación a una rueda de coche simula movimiento, pero aplicar el mismo script a un skybox puede impulsar un ciclo de día-noche. Esta dependencia espacial y jerárquica significaba que el equipo necesitaba una forma de arquitectar sistemas no solo en código, sino también en términos de colocación y jerarquía.

Para abordar esto, Mohamed Hamdy, un arquitecto de software del equipo, ideó un enfoque creativo basado en gráficos para ECS para Unity. Este método permitió al equipo diseñar entidades, componentes, autorías y sistemas de manera visual y modular, al mismo tiempo que definía su colocación y configuración. Al hacerlo, pequeños bloques de código reutilizables podrían lograr propósitos muy diferentes dependiendo de dónde se aplicaran.

El sistema se amplió posteriormente para integrar no solo entidades de ECS para Unity, sino también MonoBehaviours, GameObjects, árboles de comportamiento y el Gráfico de Comportamiento de Unity. Usando una combinación de diagramas de Lucidchart y hojas de Excel, el equipo mapeó y validó toda la arquitectura del juego de manera clara y eficiente. Mirando hacia adelante, planean construir una herramienta dedicada de Unity para hacer que este método de arquitectura sea completamente visible en el Editor, con la capacidad de validarlo contra la implementación real.

Usando un sistema de arquitectura híbrido

Después de migrar de su servidor personalizado, el equipo adoptó inicialmente un enfoque completo de física ECS para Unity. Eligieron este método por su manejo eficiente de datos y escalabilidad, especialmente en el lado del servidor, pero también por ciertas optimizaciones de renderizado del lado de la CPU.

“Una ventaja clave está en el manejo de animaciones de malla con piel a través de animación de vértices, que ECS para Unity puede procesar de manera mucho más eficiente que los sistemas tradicionales basados en huesos,” dice Alwin Joshy, artista técnico en Highstreet Market. “Sin embargo, en VR, tanto la CPU como la GPU están limitadas, y para beneficiarnos completamente de la animación basada en ECS para Unity, primero necesitábamos reducir la complejidad de la escena para liberar recursos.”

Debido a las complejas animaciones del juego, su flujo de trabajo evolucionó hacia un sistema híbrido que combina ECS para Unity con MonoBehaviours a través del Sistema de Componentes de Entidad (ECS).

Para visualizar múltiples personajes en la pantalla, descargaron parte del procesamiento a la GPU. Dado que estaba claro que la CPU se sobrecargaría por los aspectos de red y lógicos del bucle del juego, emplearon el Rukhanka Animation System.

“Para la física, construimos todo en el mundo físico principal, sincronizando todas las entidades físicas entre el servidor y el cliente,” explica Sleam. “Fue complejo al principio, ya que el servidor sincronizaba cada entidad física. Luego exploramos tener múltiples mundos físicos y enfrentamos una elección entre continuar con un calculador físico local en ECS para Unity o hacer física local en MonoBehaviour.”

MonoBehaviour permite la integración con herramientas de VR de terceros como Hurricane y Freehand, que permiten interacciones físicas realistas como presionar botones o asegurarse de que las manos no atraviesen las paredes. ECS para Unity, por otro lado, requería que el equipo construyera estos sistemas desde cero, ya que no había herramientas de terceros listas disponibles en la tienda como en MonoBehaviour.

“Al final, usamos MonoBehaviour para interacciones de VR del lado del cliente, como colisiones de manos, para asegurar la capacidad de respuesta y la inmersión,” dice Sleam. “Mientras tanto, la física del lado del servidor manejaba interacciones críticas del juego, como golpear a un monstruo, para validación.”

Este enfoque híbrido equilibra la inmersión con la seguridad, ejecutando la detección de colisiones críticas para el juego en el servidor para prevenir trampas mientras gestiona interacciones locales menos críticas en el cliente.

Reduciendo llamadas de dibujo para un rendimiento estable de VR

Mientras que ECS para Unity y Rukhanka abren posibilidades para escalar, como soportar miles de personajes animados, uno de los mayores desafíos del equipo en VR ha sido la optimización del rendimiento, especialmente bajo estrictas limitaciones de CPU/GPU.

“A diferencia de los juegos tradicionales, VR carga completamente tanto la CPU como la GPU,” explica Joshy. “Descargar no siempre es una opción a menos que la escena esté altamente optimizada.”

Después de construir el proyecto, primero realizaron una verificación preliminar de rendimiento usando la herramienta OVR stat en el Meta Quest para identificar áreas pesadas o caídas de fotogramas. Luego, crearon compilaciones de desarrollo y conectaron el Meta Quest al Unity Profiler para analizar la transferencia de datos CPU-GPU, el uso de memoria de texturas, la jerarquía de renderizado y el tiempo de dibujo.

“Para mejorar el rendimiento, recientemente nos hemos centrado en reducir las interrupciones de llamadas de dibujo controlando manualmente el renderizado. La iluminación fue un gran desafío; mientras que inicialmente horneamos mapas de luz con compresión de estilo toon para reducir el tamaño, mezclar objetos iluminados y no iluminados causó problemas de variantes de shader,” dice Joshy. “Para resolver esto, abandonamos por completo los lightmaps y adoptamos un shader toon completamente iluminado por el entorno.” Esto nos dio un rendimiento más consistente y un mejor control sobre el renderizado.”

El equipo también utilizó focos con caída escalonada y mantuvo sus variantes de shader al mínimo: solo un shader cel para clips opacos y de transparencia, y posiblemente hierba. Controlaron manualmente el orden de dibujo: objetos opacos en la capa 1, objetos transparentes en la 2 y objetos de clip en la 3. Esto ayudó a reducir las interrupciones de llamadas de dibujo al mantener el batching consistente.

“Para detectar problemas ocultos que dividen las llamadas de dibujo, dependimos en gran medida del Unity Frame Debugger para verificar el batching y el orden de dibujo,” continúa Joshy. “El perfilado de GPU también fue una de nuestras principales herramientas para optimizar el renderizado y reducir la sobrecarga de llamadas de dibujo.”

Equilibrando flexibilidad y rendimiento

A medida que el equipo escaló el desarrollo, encontraron desafíos de renderizado, especialmente en la escena de la arena donde tiene lugar el combate.

“Nuestro objetivo es mantener 72 fps en dispositivos como el Meta Quest 2, pero incluso con recuentos de triángulos por debajo de 500,000, estamos enfrentando problemas de rendimiento,” dice Joshy.

Están utilizando el SRP Batcher para reducir los cambios de shader de GPU, pero en VR independiente, las limitaciones de GPU son mucho más estrictas que en PC. “Hemos encontrado que incluso escenas con dos millones de triángulos se renderizan sin problemas, si es una sola malla con un solo material. Pero los entornos abiertos y verticales de nuestro juego hacen que ese tipo de simplificación sea impráctica,” dice Joshy.

Para mejorar el rendimiento, el equipo se centró en minimizar las llamadas de dibujo mediante:

Horneado de mallas personalizadas por el equipo de arte

Agrupando activos en sub-mallas para equilibrar el batching con la flexibilidad del material

Dividiendo el mundo y generando LOD a nivel de chunk en lugar de por activo

Transmitiendo chunks utilizando un ECS para un sistema compatible con Unity

Usar sistemas LOD por sí solo ayudó a reducir las escenas de alrededor de dos millones de triángulos a 500,000.

Este enfoque sacrificó algo de flexibilidad y aumentó la carga de trabajo para los artistas, pero era necesario dado los límites de hardware, especialmente en dispositivos como el Meta Quest 2, donde los desarrolladores no podían actualizar la GPU.

“En última instancia, minimizar las llamadas de dibujo de 80 a cinco es nuestra mayor victoria”, dice Joshy. “Estamos reestructurando el contenido y los flujos de trabajo en torno a eso, incluso si limita la variedad de materiales, porque es el camino más viable para un rendimiento estable de VR en el hardware actual.”

Escalando de manera inteligente

A medida que el equipo desarrolla su MMORPG de VR, continúan enfocándose en lo que consideran la consideración más crítica: la escalabilidad, tanto desde perspectivas de arquitectura como de gráficos.

“Si apuntas a un MMO a gran escala desde el primer día, necesitarás ECS para Unity para manejar altos conteos de entidades y redes concurrentes. Si no tienes una visión muy detallada desde el principio, escalar de manera incremental también funciona bien”, dice Qiao. “Inicialmente tomamos un enfoque de “0 a 100”, optimizando temprano para la escala máxima. En retrospectiva, construimos infraestructura en exceso demasiado pronto, consumiendo recursos que podrían haberse destinado a la jugabilidad y el contenido.”

Desde el punto de vista gráfico, el equipo es consciente de los pros y los contras de VR. “Las mallas orgánicas y suaves consumen recursos computacionales significativos y no funcionan bien en VR. Nuestro juego utiliza un estilo de dibujo animado con elementos orgánicos, lo que limita nuestro presupuesto gráfico para otras áreas como el diseño de personajes o el diseño del entorno,” dice Qiao.

En general, el equipo recomienda optar por entornos más limpios, de bajo detalle y estilo técnico para maximizar el rendimiento en tu juego de VR. “Con un diseño de escena y construcción del mundo más limpio, podrás tener más gráficos y presupuesto de recursos y gráficos para otras cosas como el diseño de personajes y el diseño estructural. Es clave diseñar con el rendimiento en mente,” dice Qiao.

Descarga Unity Pro hoy

Comienza a crear juegos que compiten con la calidad y el éxito de los títulos de los grandes estudios, e incluso los superan, con la ayuda de poderosas herramientas, soporte, socios verificados y una comunidad activa.