Cómo Ares Interactive ejecuta operaciones en vivo sin esperar actualizaciones de clientes
Adam Axler - Unity
Senior Content Marketing Manager
Para tu comodidad, tradujimos esta página mediante traducción automática. No podemos garantizar la precisión ni la confiabilidad del contenido traducido. Si tienes alguna duda sobre la precisión del contenido traducido, consulta la versión oficial en inglés de la página web.
Dirigir un juego en vivo significa construir para el cambio constante. Los equipos deben mantener a los jugadores comprometidos con nuevos eventos, actualizaciones de equilibrio, ofertas y contenido, mientras mantienen intacto el rendimiento y la estabilidad.
Ares Interactive dirige dos juegos en vivo muy diferentes: Hits de Béisbol 26, desarrollado por su equipo de 7th Inning, y The Walking Dead: Aftermath, desarrollado por su estudio Swift Games. Hits de Béisbol 26 se mantiene estrechamente ligado al calendario real del béisbol. Los Caminantes: Aftermath construye su servicio en vivo en torno a una base roguelite que puede expandirse sin interrumpir el bucle principal.
Hablamos con Andre Taube, jefe de estudio en 7th Inning, y Carsten Granig, director general de Swift Games Germany. Nos contaron cómo estructuran los sistemas de servicio en vivo, gestionan el contenido y la configuración remota, acortan los ciclos de iteración y mantienen estables los lanzamientos móviles mientras ambos juegos continúan evolucionando.
Construir operaciones en vivo en torno a los datos en lugar de los lanzamientos de clientes
Baseball Hits 26 fue creado para ofrecer a los fanáticos y jugadores de béisbol una experiencia de béisbol esencial que es fácil de empezar en cualquier momento, en cualquier lugar, en ráfagas cortas o en un juego estratégico más largo. Ese enfoque de accesibilidad se sitúa junto a decisiones de béisbol del mundo real, progresión, eventos en vivo, clubes sociales y funciones de comunicación. Mantener esos sistemas actualizados significa tratar el juego como algo que siempre está cambiando en lugar de algo que simplemente se lanzó.
Por ejemplo, si un jugador con licencia de la MLBPA se desempeña particularmente bien en un juego o serie, el equipo puede presentar a ese jugador en eventos en vivo durante la semana siguiente.
"Ese nivel de relevancia es posible gracias a nuestras ágiles actualizaciones de servidor basadas en datos y a la capacidad de nuestro equipo de operaciones en vivo para incorporar rápidamente los enfrentamientos correctos", dice Taube.
El equipo construyó su propio backend y pipeline de operaciones en vivo para poder cambiar eventos, almacenar ventas, ofertas, recompensas y ajustes de emparejamiento sin esperar un lanzamiento del cliente o un Deployment del servidor.
En la base hay un sistema personalizado de entrega de contenido y configuración remota con más de 50 dominios de configuración que cubren jugadores, eventos, artículos de la tienda, cajas de recompensa, pases de batalla y otros sistemas. El equipo gestiona los cambios a través de un panel de administración. El sistema valida los cambios antes de aceptarlos, y los servidores los captan en segundos sin necesidad de reinicio.
Todo está versionado y registrado. El equipo puede revisar o revertir a cualquier estado anterior, y puede preparar cambios contra cuentas de prueba internas antes de promocionarlos a producción.
La programación de eventos se basa en esa misma fundación. Los eventos, torneos y ventas por tiempo limitado tienen Windows de inicio y fin definidas. Un motor de segmentación gestiona la segmentación y potencia las pruebas A/B, para que el equipo pueda probar nuevas ofertas o formatos de eventos con una fracción de la audiencia antes de un despliegue más amplio.
En la práctica, eso permite que el equipo realice hasta cuatro eventos en una sola semana, como los eventos Prime Club y Tower Club, cada uno con sus propios jugadores de bonificación y ofertas destacadas asociadas.
"Poseer toda la pila rinde frutos la mayoría de las veces cuando algo sale mal en medio de un evento", dice Taube. El equipo puede diagnosticar el problema, arreglar la configuración, compensar a los jugadores afectados e implementar la actualización de [config] en los clientes, todo en minutos y todo desde un solo lugar.
Mantener la entrega de contenido y los lanzamientos móviles predecibles
El equipo utiliza Addressables específicamente para paquetes de estadios. Un estadio predeterminado viene incluido en la aplicación, por lo que los jugadores primerizos no necesitan una descarga adicional. El equipo empaqueta cada estadio alterno como un paquete, subido al servidor del equipo y descargado bajo demanda cuando un jugador lo selecciona.
El equipo somete a pruebas de estrés cada paquete de estadio en sus dispositivos de gama más baja para asegurar que se mantenga dentro de estrictos presupuestos de tamaño y memoria. Un paquete común compartido contiene recursos reutilizados en todos los estadios, por lo que los mismos datos no se duplican en cada descarga.
El mismo énfasis en la previsibilidad se aplica a los lanzamientos de iOS y Android. El equipo mantiene el código específico de la plataforma al mínimo absoluto, y ambas plataformas comparten los plazos de hitos y de entrega. El equipo crea y prueba compilaciones de Android y iOS diariamente.
Debido a que la mayor parte del contenido está impulsada por datos, el calendario en vivo no necesita estar estrechamente acoplado al momento de la revisión de la tienda de aplicaciones.
El cliente también está diseñado bajo el supuesto de que cada llamada al servidor puede fallar.
"Para los juegos en vivo específicamente, trata cada llamada al servidor como no confiable por defecto", dice Taube. "Estructurar el cliente para que un servidor lento, caído o no receptivo nunca rompa la experiencia del jugador."
Ese principio se aplica al soporte de dispositivos. El equipo utiliza el Simulador de Dispositivos para verificar la cobertura de la interfaz de usuario en todo el rango de tamaños y resoluciones de pantalla que admite. El Unity Profiler se utiliza ampliamente para encontrar problemas de rendimiento durante el juego. El equipo también prueba regresiones de rendimiento en una amplia gama de dispositivos físicos Android y iOS, tanto con como sin Wi-Fi.
Para Taube, los equipos móviles deben definir su estrategia de dispositivos temprano.
"Invierte temprano en un plan arquitectónico sólido para el soporte de dispositivos, especialmente en Android, donde la fragmentación entre hardware y versiones de OS es el verdadero riesgo."
Construyendo The Walking Dead: Consecuencias para que los sistemas en vivo puedan evolucionar de forma independiente
Baseball Hits 26 está construido para reflejar un calendario deportivo del mundo real. Los Caminantes: Aftermath tiene un desafío de servicio en vivo diferente: añadir nuevas formas de jugar sin alterar su experiencia roguelite subyacente.
El RPG de acción roguelite sitúa a los jugadores en el mundo de The Walking Dead. Construyen equipos de Supervivientes, incluyendo a Rick Grimes, Daryl Dixon y Michonne, y luchan contra hordas de Caminantes y otros enemigos en combate en tiempo real. Entre partidas, los jugadores desbloquean Supervivientes y Equipo, los suben de nivel, desbloquean habilidades y construyen su base.
"En esencia, queríamos crear algo que capture el peligro constante y las difíciles decisiones de The Walking Dead mientras ofrece la rejugabilidad y la progresión que esperas de un roguelite", dice Granig.
El servicio en vivo se basa en esa fundación con desafíos y restricciones, además de sistemas sociales como Alianzas, eventos cooperativos y Leaderboards.
Desde un punto de vista de desarrollo, construimos el juego para que esos sistemas puedan evolucionar de forma independiente. Eso nos da la flexibilidad para seguir expandiendo la experiencia en vivo sin interrumpir el bucle roguelite principal.
Hacer la décima característica en vivo tan barata de enviar como la primera
Swift Games no reconstruyó su base de servicio en vivo desde cero. Comenzó desde su título en vivo anterior, Heroes vs Hordes. Los sistemas de almacenamiento, Economy, Authentication, Analytics, configuración remota y guardado en la nube parecían tecnología probada, mientras que el núcleo roguelite nuevo se prototipó por separado y luego se fusionó en esa base.
Cualquier cosa que se esperaba que cambiara semanalmente fue diseñada para cambiar sin un lanzamiento del cliente. Los diseñadores autorizan contenido y equilibrio en hojas de cálculo y los publican como paquetes remotos, con cada paquete marcado con las versiones del cliente que soporta.
Los datos guardados están versionados con una cadena de migración, por lo que una actualización en vivo nunca deja huérfano a un jugador de mucho tiempo. El tiempo proviene del servidor en lugar del dispositivo, porque los eventos y las ofertas programadas dependen de él.
La compensación es que las funciones en vivo deben diseñarse no solo para activarse, sino para desactivarse de forma segura.
"Eso es lo que mantiene la décima característica en vivo tan barata de enviar como la primera", dice Granig.
El juego utiliza principalmente GameObjects y NVIDIA PhysX. Entities y Burst están reservados para el sistema de búsqueda de caminos A* que mueve a los enemigos.
Más importante para el desarrollo de la vida es la inyección de dependencias con alcance. El juego tiene cuatro contextos anidados: raíz, guardar partida, pantalla principal y jugabilidad. Cada contexto es responsable de lo que crea y de limpiarlo.
Eso significa que un evento en vivo puede estructurarse como un instalador más un archivo de configuración conectado a un contexto. Cuando ese contexto se cierra, sus activos y suscripciones se van con él.
El equipo también separa la interfaz de usuario de la lógica. Una tienda u oferta puede existir como una clase C# simple que se puede probar sin iniciar el Motor, mientras los diseñadores trabajan directamente con los activos de configuración.
Trazar una línea clara entre los datos en vivo y los activos del juego
En The Walking Dead: Aftermath, Addressables manejan la gestión de memoria y la carga en lugar de la entrega de contenido remoto. Veintinueve grupos corresponden a características individuales, y se cargan y descargan de manera muy similar a los contextos del juego.
El contenido en vivo sigue un pipeline separado construido directamente sobre la API AssetBundles en lugar de Addressables. Los paquetes se construyen por plataforma, se suben y se obtienen por el juego en tiempo de ejecución. Cada uno incluye un hash, una suma de verificación y la versión más antigua compatible del cliente.
La regla del equipo es simple: Si los diseñadores quieren cambiarlo cada semana, debe estar en un paquete. Si es arte o código, pertenece a la compilación.
Dentro de ese límite, el equipo aún puede mover eventos, reequilibrar recompensas, ajustar ofertas, activar o desactivar funciones o comportamiento de compra y ejecutar pruebas A/B sin volver a las tiendas. Nuevo arte y nuevo código requieren una compilación.
"Establecimos ese límite intencionalmente para que la superficie viva se mantenga lo suficientemente pequeña como para que, cuando algo se rompa, podamos identificar qué cambió", dice Granig.
La variedad visual sigue un enfoque igualmente controlado. Las arenas se construyen a mano en lugar de generarse proceduralmente. En lugar de duplicar entornos, el equipo cambia su aspecto a través de materiales, iluminación y sombreadores en la geometría existente. Alrededor de 35 gráficos de sombreado y 10 sombreadores escritos a mano componen ese sistema.
"Debido a que las arenas están construidas a mano, podemos contabilizar todo lo que un jugador podría ver y medirlo todo, en lugar de muestrear y esperar."
The Walking Dead: Aftermath | Swift Games studio | Ares Interactive
Acortando el camino desde la hoja de cálculo hasta el juego en vivo
Gran parte de la velocidad de las operaciones en vivo del equipo proviene de las herramientas.
Los diseñadores editan la configuración ellos mismos. Los importadores internos extraen capítulos, texto y tablas de recompensas directamente de las hojas de cálculo, y la hoja de cálculo sigue siendo la fuente de la verdad.
El resultado: Si el equipo detecta un problema de operaciones en vivo o de equilibrio, puede implementar una solución en unos 15 minutos en lugar de pasar por un proceso de lanzamiento completo.
La tubería de compilación también está diseñada para acortar el tiempo de iteración. El perfilado profundo es un interruptor de compilación en lugar de una rama dedicada, por lo que los desarrolladores pueden solicitar una compilación de perfilado de lo que sea en lo que están trabajando cuando sospechan una regresión. Trabajar en el almacenamiento en caché y los tiempos de compilación también ayuda al equipo a manejar la gran cantidad de compilaciones que produce cada día.
Debido a que los cambios de la interfaz de usuario se envían semanalmente, el equipo depende del Simulador de Dispositivos para verificar el notch y el área segura en diferentes formas de pantalla. No reemplaza las pruebas de dispositivos físicos, pero detecta problemas de diseño antes.
El problema operativo más difícil provino de separar los entornos de desarrollo y en vivo. La configuración de Firebase está incrustada en los archivos de compilación, y las claves de Firebase, Play Services, la configuración de Facebook, los ID de paquete, los nombres y los iconos deben coincidir todos.
El equipo finalmente trasladó la responsabilidad de esos entornos a la integración continua (CI). Los desarrollos y las compilaciones en vivo utilizan diferentes IDs de paquete, nombres e iconos, para que puedan coexistir en el mismo dispositivo. Si una compilación de desarrollo se conecta al servidor en vivo, aparece una advertencia en el juego. Las cargas fallan cuando falta la configuración, en lugar de apuntar silenciosamente al entorno equivocado.
"Movemos la responsabilidad a CI en lugar de dejarla a las personas", dice Granig.
Bases de béisbol 26 | Séptima entrada | Ares Interactive
Empieza pequeño, prueba temprano
Ambos equipos llegan a la misma lección desde diferentes direcciones: El desarrollo de vida sostenible depende de decidir temprano qué necesita cambiar, aislarlo de lo que debe permanecer estable y construir sistemas que asuman que algo saldrá mal eventualmente.
Para Baseball Hits 26, eso significa un backend impulsado por datos que puede reaccionar rápidamente a la temporada real de béisbol mientras evita que las liberaciones de clientes, los dispositivos y los fallos del servidor interrumpan el juego.
Para The Walking Dead: Consecuencias, eso significa sistemas vivos modulares, configuración estrictamente controlada y un límite deliberado: El contenido puede cambiar de forma remota, mientras que el código y el arte se envían en la compilación.
El consejo de Granig para los equipos que se acercan a su primer juego móvil en vivo es demostrar la experiencia central antes de construir la maquinaria de servicio en vivo a su alrededor.
"Prepara uno a tres días de contenido y lánzalo antes de trabajar en cualquier otra cosa." Luego mira cuántos jugadores vuelven al día siguiente. Si no regresan, ninguna cantidad de contenido de fin de juego lo rescatará", explica.
Entonces hazlo de nuevo. Añade contenido, mira el día tres y repite. Empieza pequeño, prueba temprano y deja que los números te digan si el juego funciona. La parte difícil es decir no a todo lo que quieres construir hasta que el bucle central se demuestre.
Hits de Béisbol 26 y The Walking Dead: Aftermath están disponibles ahora en App Store y Google Play. Echa un vistazo a más historias de desarrolladores de Unity en el Blog de Unity y en el Resource Hub.