Cómo Hologryph construyó SAND: Los asaltantes de Sophie para una cadencia de operaciones en vivo sostenible

Para Hologryph, el desarrollo ARENA: Los asaltantes de Sofía Esto significaba convertir un páramo desértico de historia alternativa de 1910 en un juego de extracción que pudiera seguir creciendo mucho después de su lanzamiento. Los jugadores tripulan y pilotan los Tramplers, gigantescas máquinas andantes que sirven como base, depósito de botín y arma al mismo tiempo, y luego los montan a través de un mundo abierto generado proceduralmente en busca de objetos rescatados y de otros jugadores.

Para ofrecer esa experiencia, se requirió una estricta separación entre servidor y cliente, una generación de mundo procedural que se ejecuta de forma idéntica en ambos lados, la sincronización de los cientos de entidades que componen un solo Trampler y una transmisión del mundo lo suficientemente fluida como para transmitir la sensación de montar uno. El equipo también necesitaba un sistema de producción de contenido lo suficientemente rápido como para lanzar nuevos compartimentos, armas, efectos y entornos de temporada con regularidad sin desestabilizar el rendimiento.

Hablamos con Serhiy Grinets, director de tecnología y director de juego de Hologryph, sobre la arquitectura del juego a largo plazo, el mantenimiento del flujo de contenido y lo que se necesita para gestionar las operaciones en vivo de un juego tan ambicioso desde el punto de vista técnico.

¿Cómo es vuestro modelo de operaciones en directo y qué implica una actualización típica?

Serhiy Grinets: Nuestro modelo de operaciones en vivo para SAND se centra en mantener el juego en constante evolución junto con nuestra apasionada comunidad. Nuestra prioridad es mantener un ritmo regular de actualizaciones que combinen contenido nuevo, mejoras en la jugabilidad, ajustes de equilibrio, correcciones de errores y cambios que mejoren la experiencia de juego. Nuestro objetivo final es construir un modelo de operaciones en vivo sostenible que respalde el título a largo plazo.

¿Cuáles eran sus principales objetivos técnicos al comenzar el proyecto y cómo influyeron en su enfoque para crear un juego diseñado para perdurar y evolucionar a largo plazo?

Teníamos tres grandes objetivos:

• Una estricta separación entre un servidor autoritativo y un cliente, con generación de mundo procedimental que se ejecuta de forma idéntica en ambos lados.
• Sincronizar una enorme cantidad de entidades: un solo Trampler está compuesto por cientos de ellas.
• Transmisión fluida del mundo: el mundo es realmente grande, y para vender la sensación de montar en un Trampler, necesitas un lugar donde montar.

Los pisoteadores son fundamentales para la identidad del juego. ¿Cómo diseñasteis el sistema de personalización para poder lanzar nuevas piezas, elementos cosméticos y variantes como contenido continuo para las operaciones en vivo?

Todo el sistema está construido en torno a compartimentos. Un compartimento es una sección de un Trampler (una cubierta, una cabina, un bastidor de soporte, una sala de equipos) y cada compartimento está diseñado para encajar con los demás.

Los jugadores ensamblan su Trampler a partir de estos bloques: Eligen la distribución, apilan las cartas, colocan el equipo y terminan con una máquina que es verdaderamente suya: su base, su bóveda y su arma al mismo tiempo.

Para nosotros, como desarrolladores, este es también el flujo de contenido. Para añadir un nuevo compartimento, lo modelamos y configuramos sin necesidad de código. Se integra al sistema de construcción como cualquier otro bloque, y los jugadores pueden usarlo inmediatamente en sus diseños. Un programador solo interviene cuando una pieza necesita un nuevo mecánico, e incluso entonces se trata de un trabajo pequeño y aislado.

Eso es lo que hace que los compartimentos sean perfectos para el contenido de operaciones en vivo: Cada nueva unidad multiplica el número de construcciones posibles de Trampler, y su producción nos resulta económica.

¿Qué aspecto tiene la arquitectura subyacente al sistema de compartimentos y cómo permite crear prototipos de nuevos mecanismos rápidamente?

Utilizamos un enfoque modular que nos permite iterar rápidamente sobre los prototipos. Internamente, contamos con un contenedor de inversión de control personalizado para integrar nuevas funcionalidades, y se adapta muy bien a nuestro Sistema de Componentes de Entidades (ECS). Además, nuestro motor de red personalizado significa que casi nunca tenemos que pensar en la conectividad de red al crear nuevas mecánicas. La replicación se gestiona en una capa inferior al código del juego.

¿Cómo te proporcionaron el sistema de trabajos de C# y el compilador Burst de Unity el margen de rendimiento necesario para seguir añadiendo contenido de operaciones en vivo sin regresiones?

Nuestra simulación se ejecuta en nuestra propia versión modificada de Entitas, un marco ECS de código abierto, en lugar de Unity Entities, pero el sistema de trabajos de C# y el compilador Burst son fundamentales para nuestras rutas críticas. La generación procedural del terreno, que incluye tareas de muestreo de mapas de altura y biomas, cálculos de movimiento de Trampler y nuestro sistema personalizado de eliminación de oclusiones, se ejecutan como cadenas de tareas compiladas por Burst. Ese trabajo se mantiene fuera del hilo principal, por lo que un mundo más denso no nos cuesta fotogramas.

¿Qué papel desempeñó VFX Graph a la hora de permitir que su equipo iterara rápidamente en los efectos para eventos en directo, momentos de temporada o logros importantes?

Todos nuestros efectos (arena, polvo, humo, escudos, efectos de armas) están creados con VFX Graph, pero la clave está en cómo lo utilizamos. Además, creamos sistemas de efectos configurables, como el destello de la boca del cañón o el impacto de una bala, que existen como un gráfico flexible con un amplio conjunto de parámetros expuestos, que incluyen tamaño, color, sincronización, escombros y humo.

Así, cuando aparece una nueva arma, un artista simplemente ajusta esos parámetros y consigue un efecto único; no interviene ningún artista técnico ni se crea un nuevo gráfico desde cero. El tiempo de los artistas técnicos se dedica a enriquecer estos sistemas en lugar de crear manualmente cada efecto para esa arma.

Eso es lo que permite que la producción sea lo suficientemente rápida como para mantener un ritmo constante de publicación de contenido. Las nuevas armas y eventos obtienen efectos de calidad a costa de la configuración, no del desarrollo.

¿Cómo influyó Unity Profiler en tu flujo de trabajo de optimización a medida que aumentaba la escala de tu canalización de contenido de operaciones en vivo?

Medimos periódicamente el rendimiento tanto del cliente como del servidor para detectar y optimizar los puntos débiles. El desglose por sistema en Unity Profiler muestra exactamente en qué se invierte el tiempo, lo que hace que nuestro ECS sea muy fácil de perfilar.

También contamos con pruebas automatizadas que miden el rendimiento en escenarios fijos, por lo que podemos observar la tendencia a diario y reaccionar a los cambios de inmediato.

¿Cómo utilizas Addressables para implementar actualizaciones de contenido en tiempo real, correcciones urgentes y lanzamientos de temporada sin necesidad de actualizar completamente el cliente?

Las Addressables son la columna vertebral de nuestra gestión de memoria. El mundo se transmite en directo: Mientras los jugadores atraviesan el desierto, el contenido se carga y descarga constantemente detrás de ellos. Todo eso pasa por Addressables, por lo que la memoria permanece plana sin importar qué tan lejos se desplacen los jugadores.

Una segunda función, menos obvia, es que tenemos dos proyectos separados: el proyecto principal del cliente y el proyecto del servidor, y desarrollamos una solución personalizada que transfiere activos de uno a otro. Eso mantiene la coherencia en ambos entornos: El servidor ve los mismos datos que el cliente, generados a través del mismo proceso, por lo que los errores de contenido del tipo "funciona en el cliente, pero falla en el servidor" son estructuralmente imposibles, en lugar de algo que tengamos que probar.

¿Hubo alguna herramienta de Asset Store que te ayudara a crear o mantener tu flujo de operaciones en vivo más rápidamente?

Desde la Unity Asset Store, GPU Instancer Pro renderiza todos los elementos dispersos del desierto, que son esenciales para el mundo abierto, y Amplify Impostors se encarga de los objetos distantes. Odin Inspector impulsa nuestras herramientas para diseñadores, lo cual es clave para un flujo de trabajo de contenido basado en datos, y Rewired gestiona la entrada de datos tanto en PC como en consolas. Easy Save , DOTween e I2 Localization nos ahorraron mucho tiempo.

¿Qué papel desempeñó Cinemachine a la hora de capturar momentos dignos de ser compartidos y destacados (batallas de mechas, jugadas espectaculares) que impulsan tu estrategia de contenido?

Nuestro uso de Cinemachine es deliberadamente sencillo. Gestiona nuestras cámaras y alterna entre ellas: la cámara de juego, la del hangar y la de espectador. No añadimos ninguna puesta en escena adicional ni cinematografía guionizada, y es una decisión consciente. ARENA: Los asaltantes de Sofía Es un juego en primera persona, altamente competitivo, y la función de la cámara es ser fiable, no artística.

La calidad cinematográfica proviene del propio juego. Cuando dos gigantescas fortalezas andantes intercambian disparos de cañón, y tú estás en la cubierta de una de ellas recargando un arma, ninguna secuencia de cámara guionizada puede superar eso. La grandeza de la simulación reside en su cinematografía. Cinemachine se asegura de que la cámara nunca estorbe.

Has configurado un sistema Vivox de doble canal: chat para la tripulación y chat de proximidad espacial. ¿Qué implicó diseñar e implementar eso?

Cada jugador está en dos canales de Vivox a la vez: el canal habitual de la tripulación, que es la "radio" donde tu tripulación siempre te escucha, y un canal posicional mediante voz de proximidad 3D , para que escuches a los jugadores cercanos de otras tripulaciones en el mundo.

El canal posicional utiliza las propiedades 3D de Vivox (rango, atenuación, modelo de desvanecimiento) ajustadas en un archivo de configuración. Nuestro sistema ECS envía la posición del altavoz y del oyente a Vivox a una velocidad limitada, solo unas 20 veces por segundo y únicamente cuando el jugador se ha movido. La autenticación se realiza a través de nuestro propio servicio de tokenización de backend.

Más allá de la voz, ¿cómo influyó Vivox en su estrategia general de operaciones en vivo y cómo ayudó a impulsar la participación y la retención en redes sociales?

La comunicación por voz por proximidad es una función del juego, no solo para comunicarnos. Los juegos de extracción se basan en momentos sociales espontáneos, donde los equipos que se encuentran en el desierto pueden hablar, negociar, formar equipos o traicionarse entre sí, y escuchar la voz real de un desconocido cerca crea una tensión que ningún sistema guionizado puede generar. La radio de la tripulación mantiene a los equipos coordinados.

¿Cuál es tu mejor consejo para los desarrolladores que buscan crear un juego basado en operaciones en vivo?

Desarrollar un juego con operaciones en vivo es un proceso desafiante, así que asegúrate de que tu equipo tenga la capacidad de adaptación necesaria para llevarlo a cabo y de que cuentes con socios y herramientas fiables. Mantente cerca de tu comunidad: escucha a tus jugadores, aprende de sus comentarios y deja que estos ayuden a dar forma a la evolución del juego con el tiempo.

Para obtener más información sobre proyectos realizados con Unity, visite la página de Recursos .