La pila multijugador detrás del MMORPG Pantheon: Rise of the Fallen

Encontrar tu propio camino es el núcleo de la jugabilidad enPantheon: El Ascenso de los Caídos – los jugadores pueden ir a cualquier parte, escalar cualquier cosa, forjar nuevas rutas y seguir su curiosidad para encontrar aventura. No es tan diferente de cómo sus creadores, Visionary Realms, abordan la construcción de este MMORPG – lo están haciendo a su manera.

Transportando a los jugadores al mundo de fantasía de Terminus, Pantheon: El Ascenso de los Caídos recuerda a los MMOs clásicos, donde el descubrimiento accidental al vagar por un mundo abierto y las interacciones sociales con otros jugadores están en el corazón de la experiencia del juego.

Crear cualquier juego multijugador es un desafío – pero un juego en línea altamente social a esta escala es una búsqueda épica. Nos sentamos con el programador principal Kyle Olsen sobre cómo el equipo está utilizando Unity para conectar a los jugadores en este mundo de fantasía MMORPG.

Entonces, ¿qué hace que Pantheon: El Ascenso de los Caídos sea único en comparación con otros juegos MMO?

Definitivamente es el aspecto social.Tienes que experimentar el mundo y moverte a través de él de manera natural.Puede ser un poco más de un esfuerzo en cierto modo, pero creo que te conecta más con tu personaje, con el juego y el mundo en lugar de simplemente teletransportarte a todas partes y unirte a sistemas LFG o simplemente ser colocado en una mazmorras. Aprendes la tierra un poco mejor, tienes que navegar y usas tus ojos más que simplemente rebotar como una bola de pinball de objetivo a objetivo, siguiendo marcadores de misiones y cosas así. Es más un juego de pensamiento.

¿Cómo estás gestionando la sincronización entre la experiencia del jugador y las instancias específicas del mundo?

Tenemos nuestra propia biblioteca de red que construimos para la capa de transporte de socket llamada ViNL. Esa es la base para todas las comunicaciones de zona, entre zonas y de jugador a zona. Servidor SQL en el backend, cosas estándar allí. Pero la mayoría de los transportes son manejados por nuestra propia biblioteca de red.

¿Cómo abordas la carga de activos para este mundo gigante?

Tenemos un paso donde horneamos nuestros continentes en estos mosaicos, y tenemos diferentes backends a los que podemos conectarnos. Tenemos uno que simplemente genera Prefabs estándar, y tenemos uno que genera subescenas que estábamos usando antes de Unity 6, y luego tenemos escenas completas de Unity que puedes cargar aditivamente, así que puedes elegir cómo quieres exportar tu contenido. Antes de Unity 6, nos habíamos alejado de los Prefabs y comenzamos a cargar las subescenas DOTS y usar eso, construido sobre BRG.

También tenemos una salida que puede renderizar directamente a nuestro propio grupo de renderizado por lotes personalizado, utilizando objetos scriptables y gestionando nuestros propios datos. Así que hemos podido experimentar y probar los diferentes, y ver cuál ofrece el mejor rendimiento del cliente. Antes de Unity 6, estábamos exportando y renderizando todo el continente con subescenas, pero con Unity 6 en realidad volvimos a usar Prefabs con Instantiate Async y Addressables para gestionar todo.

Estamos usando el Drawer Residente y ocultación de oclusión GPU, que terminó ofreciendo un rendimiento aún mejor que las subescenas y nuestro propio grupo de renderizado por lotes – asumo que porque la ocultación de oclusión GPU simplemente no es compatible con algunos de los otros caminos de renderizado en este momento. Así que hemos estado probando bastante, y aterrizamos en Addressables para gestionar toda la memoria y la carga de activos, y el uso regular de Prefabs Instantiate con el Drawer Residente GPU parece ser el mejor rendimiento del lado del cliente en este momento.

¿Actualizaste a Unity 6 para aprovechar el Drawer Residente GPU, específicamente?

En realidad, lo quería mucho por la ocultación de oclusión. No estaba al tanto de que solo ciertos caminos de renderizado hacían uso de la ocultación de oclusión, así que estábamos intentando usarlo con el mismo renderizado de subescena que estábamos usando antes de Unity 6 y dándonos cuenta de que en realidad no se estaba ocultando nada. Así que optamos por volver a la salida de Prefab para ver cómo se veía eso con el Drawer Residente, y la ocultación de oclusión y FPS aumentaron.

Tuvimos algunos problemas inicialmente, porque Instantiate Async no estaba disponible antes de Unity 6, así que tuvimos algunos retrasos cuando instanciábamos nuestros mosaicos. Había bastantes cosas siendo instanciadas, pero al cambiar eso a Instantiate Async después de arreglar un par de errores, eliminamos el retraso en la carga y la tasa de fotogramas general fue más alta después de la carga, así que fue una victoria total.

¿Hubo alguna ganancia de productividad realmente notable que vino con el cambio a Unity 6?

Todo lo que he mencionado hasta ahora fue orientado al cliente, así que nuestros jugadores experimentaron esas victorias. Para el lado del desarrollador, la estabilidad y el rendimiento del Editor aumentaron bastante. La estabilidad del Editor en Unity 6 ha aumentado bastante; es muy raro que se bloquee ahora. Eso solo ha sido, al menos para el lado de la codificación, una gran victoria. Se siente más estable en su totalidad, sin duda.

¿Cómo manejas los cambios y actualizaciones sin romper todo?

Construimos con Addressables utilizando las etiquetas de manera muy intensiva, y hacemos el empaquetado de Addressable por etiquetas. Así que si editamos una zona específica o un activo en una zona, o como un VFX asociado con un hechizo o algo así, solo esos paquetes que tocan esa etiqueta se actualizan.

Y luego, nuestro propio sistema de entrega de contenido, tenemos el juego disponible en Steam y nuestro propio parcheador, y ambos manejan los cambios delta, donde solo estamos entregando pequeñas actualizaciones a través de esos paquetes Addressable. El netcode requiere que la misma versión esté conectada en primer lugar, así que el lado de la biblioteca de red de eso se maneja automáticamente en el proceso de apretón de manos.

¿Qué orientación le darías a alguien que está tratando de abordar un juego MMO u otro proyecto multijugador ambicioso?

Supongo que comienzas pequeño. Es un proceso paso a paso. Si eres un equipo pequeño, comienzas pequeño. Es un proceso paso a paso. Si eres un equipo pequeño, no puedes abarcar demasiado. Sería completamente abrumador, pero eso es cierto con cualquier juego de mayor escala, no solo un MMO.

Probablemente la selección de tecnología: tomar decisiones inteligentes desde el principio y mantenerlas. Va a haber mucho middleware y tecnología de backend que tendrás que manejar y hacer que funcionen bien juntos, y cambiar a la cosa más nueva y genial todo el tiempo no va a ser bueno.

¿Cuál es el logro técnico más emocionante para tu equipo con este juego?

Creo que no hay muchos MMOs de mundo abierto, en general, que se hayan realizado en Unity. No tenemos un gran equipo, y estamos haciendo un juego que es genuinamente masivo, así que tenemos que enfocarnos en pequeñas áreas aisladas, desarrollarlas lo mejor que podamos y luego avanzar y obtener retroalimentación.

Todo el paquete juntos son terrenos bastante nuevos; cuando hay un MMO, debe sentirse como un MMO en espíritu, con muchas personas alrededor, haciendo lo suyo. Y lo hemos logrado; creo que mejor que prácticamente cualquier MMO de Unity lo ha hecho. Creo que podemos darnos una palmadita en la espalda por eso.

Obtén más información de los desarrolladores en la Página de Recursos de Unity y aquí en el blog. Echa un vistazo a Pantheon: Rise of the Fallen en Acceso Anticipado en Steam.