Inmersión en el servidor: poder estético

Capsulista:

Es hora de continuar con la conversación sobre Quasar, el ecosistema subyacente del desarrollo moderno en EVE Online. Desde su presentación en el Fanfest 2022, se ha convertido en la base de varios avances importantes, entre ellos:

Este viaje, como parte de EVE Evolved, ha explorado la teoría de conjuntos, la teoría de grafos y, eh… la teoría del color. Sin embargo, hoy queremos centrarnos en la tecnología que impulsa las SKIN de naves creadas por los capsulistas, porque es mucho más que un editor sofisticado y una maravilla del sombreado. De hecho, es una pieza clave para desbloquear futuras mejoras en el rendimiento del servidor. Prepárate, porque será necesario un par de cursillos acelerados para entender a fondo en qué ha estado trabajando el equipo.

Netcode y frecuencia de tics

Uno de los desafíos más comunes en los juegos multijugador es su arquitectura de red, conocida coloquialmente como «netcode». Ya sea para garantizar una experiencia coherente para todos los jugadores o para prevenir trampas, la forma en que la información se transmite a los clientes del juego desempeña un papel crucial en el rendimiento y la diversión general. Un factor clave en esto es la frecuencia de tics, que determina con qué frecuencia el servidor del juego actualiza y envía información a los clientes conectados.

Los diferentes motores de juego abordan esto de maneras distintas. Unreal Engine, por ejemplo, enfatiza el filtrado de relevancia, y envía solo las actualizaciones más importantes a cada cliente, mientras que Source Engine se centra en la predicción de entradas, lo que reduce la cantidad de correcciones necesarias para mantener un juego fluido.

Independientemente del enfoque, la frecuencia de tics sigue siendo un factor fundamental en el rendimiento de la red. La mayoría de los juegos operan entre 20 Hz y 120 Hz, dependiendo del número de jugadores en línea, lo que significa que se envían actualizaciones entre 20 y 120 veces por segundo a cada cliente. Por ejemplo, a 60 Hz, el servidor debe procesar y enviar actualizaciones cada 16,6 milisegundos para garantizar que se realicen 60 actualizaciones por segundo y, al mismo tiempo, permitir que otros jugadores reciban la misma información dentro del mismo periodo. Suponiendo una conexión mágica sin latencia que lleve el estado del juego directamente a los clientes en el momento de la conexión (vamos a imaginar que eso existe), un servidor a 60 Hz procesaría las actualizaciones del estado del juego de la siguiente manera:

Dos tics de un servidor de 60 Hz

La predicción de entradas y la interpolación de movimiento pueden crear la ilusión de una interacción casi en tiempo real, incluso sin una conexión mágica de latencia cero. Pero a medida que la frecuencia de tics disminuye, los retrasos se vuelven más notorios. Suena mal, ¿verdad? Entonces, ¿por qué querrías una frecuencia de tics más baja?

Bueno, EVE Online ha existido desde los días de los módems de 56 k. Para mantener los requisitos de ancho de banda lo suficientemente bajos como para soportar batallas espaciales masivas, la frecuencia de tics del servidor se fijó en un segundo.

Más específicamente, la frecuencia de tics de la simulación de física es de 1 Hz, lo que reduce de forma drástica la necesidad de enviar actualizaciones a los clientes de escritorio.

Otras interacciones con elementos que no afectan a la física se procesan tan rápido como los «hámsters» de Python lo permitan. Esto significa que, si se envía una entrada justo antes de un tic, se siente muy sensible. Si se envía justo después, puede parecer que tarda un segundo o incluso más en mostrar un efecto (cuando se tiene en cuenta la latencia real... Vale, vale, Australia). Técnicamente, por lo tanto, podrías sincronizarte bien con el servidor pulsando una tecla exactamente una vez por segundo, pero, por supuesto, para el bienestar mental, puede ser muy importante hacer clic en «Saltar» treinta veces por segundo.

Si observamos de manera global Tranquility por término medio durante el último año, está claro que el número de operaciones por segundo es proporcional al número de capsulistas activos en el cúmulo. Por término medio, cada sesión procesa alrededor de 0,7 operaciones por segundo, lo que demuestra lo eficiente que es EVE Online al transmitir solo los datos necesarios.

Por supuesto, las cifras fluctúan y son promedios. Cuando las batallas de flotas alcanzan los límites de procesamiento, se activa la dilatación del tiempo (TiDi, por sus siglas en inglés). Si tienes curiosidad sobre los detalles prácticos de esto, puedes consultar el archivo de TiDi para obtener más información.

¿Y dónde entran las SKIN en todo esto?

Casi todos los mecanismos estéticos de EVE Online se envían a través de marcos de simulación, la versión de EVE de un tic. Antes del SKINR, los cambios de SKIN de las naves se enviaban con el siguiente marco de simulación que se enviaba a todos los clientes relevantes. En otras palabras, las actualizaciones de SKIN solo podían ocurrir una vez por segundo. Incluso sin ningún límite de velocidad en la interfaz de usuario o en las solicitudes de red, independientemente de la rapidez con la que se cambiaran las SKIN, nadie podría ver más de una actualización por segundo, porque ese es el límite en la transmisión de marcos de simulación.

También hay otro problema: la difusión. (Último cursillo acelerado, lo prometo).

Cuando cambias la SKIN de tu nave, la actualización debe enviarse a varios destinatarios, lo que se conoce como «difusión». Pero ¿cuáles deben recibir la información? ¿Qué sucede si estás cerca de otras cien naves? ¿Qué significa «cerca» en realidad y quiénes son las otras cien?

Los marcos de simulación se ocupan de ambos problemas al procesar únicamente las actualizaciones de las naves dentro de la misma burbuja (coloquialmente llamada cuadrícula, que no debe confundirse con las burbujas de disrupción de warp). Sin embargo, este enfoque tiene un coste, ya que más datos por marco de simulación significa más serialización y difusión para el servidor que simula ese sistema solar. Anteriormente, Quasar solo rastreaba en qué sistema solar se encontraba una nave, pero para que el SKINR funcionara en tiempo real, también tenía que rastrear el movimiento de las naves entre las burbujas.

Esta no ha sido una tarea fácil. Han sido necesarios cambios profundos en el motor de simulación central de EVE Online para permitir que Quasar accediera a su estado de una manera que no se había hecho antes. ¡El resultado ha sido sorprendente! Un enorme aumento de 27 veces en los datos procesados en comparación con las simples transiciones entre sistemas solares.

He aquí una comparación de eventos por segundo entre el viaje por el sistema solar y el viaje por burbujas; ten en cuenta que el warpeo atraviesa múltiples burbujas, no solo de «A a B».

¡Y eso es solo el tráfico interno, sin siquiera considerar el problema de la difusión!

Resolver el desafío de la difusión

Ahora, volvamos al escenario de «una nave que cambia su SKIN cerca de otras 100 naves». Como Quasar rastrea todas las naves en todas las burbujas, ahora entiende qué significa «cerca» y qué clientes necesitan recibir actualizaciones. En lugar de esperar al siguiente marco de simulación, Quasar envía inmediatamente los cambios de SKIN a todos los que se encuentran en una burbuja determinada.

Esto es posible gracias a los mensajes del poderoso NATS, que maneja de manera eficiente los aproximadamente 10 000 mensajes que se envían a los clientes de EVE cada segundo. Los servicios como los que manejan el estado estético ahora pueden serializar y enviar una única actualización de SKIN, que luego se distribuye a todas las naves cercanas, en lugar de retrasarse por el tic de simulación de 1 Hz.

Esto se demuestra en este clip rápido de una prueba de juego del SKINR:

La pregunta es: ¿por qué es importante que Quasar pueda rastrear la ubicación de las naves y enviar actualizaciones del estado estético de forma independiente? Porque esta técnica permite a EVE Online descargar una función puramente estética del motor de simulación principal.

Además, tiene implicaciones más amplias cuando se consideran todos los demás efectos estéticos que deben serializarse y distribuirse entre los clientes. Una vez que la conversación va más allá de los elementos estéticos, la pregunta natural es: ¿qué más se podría descargar en Quasar?

Llevando los límites al máximo

Para probar el sistema, parte de la prueba masiva del SKINR implicó quitar el limitador de la interfaz de usuario al cambiar de SKIN para ver qué sucedía. ¿El resultado? Un efecto visible bastante interesante:

La parte divertida fue cuando comenzó la verdadera prueba de estrés, con 500 jugadores bombardeando de manera simultánea cambios de SKIN en la misma burbuja en un servidor de prueba. ¡Esto dio como resultado que el sistema alcanzara un pico de aproximadamente 45 000 mensajes por segundo!

Queremos expresar nuestro más sincero agradecimiento a todos los que participan en este tipo de pruebas masivas. Puede que no siempre resulte evidente lo valiosa que es vuestra contribución, pero esto ilustra claramente el impacto que tiene vuestra participación.

Ahora regresemos al ejemplo caótico anterior. ¿Qué ha conseguido exactamente?

Si nos fijamos en las estadísticas anteriores, Tranquility suele gestionar unos 30 000 mensajes por segundo en todo el servidor, lo que supone un buen promedio de una operación por segundo o 1 Hz. En cambio, la prueba del SKINR alcanzó los 45 000 mensajes por segundo con solo 500 jugadores, lo que significa que Quasar estaba enviando actualizaciones a 90 Hz en ese escenario.

Si Quasar puede proporcionar tráfico de 90 Hz para 500 jugadores en un servidor de prueba a pequeña escala que ejecuta solo tres nodos, ¿qué podría hacer si se ampliara a la potencia total de 230 nodos de Tranquility con 30 000 jugadores activos?

¿Qué sucede si los propios marcos de simulación siguen el mismo paradigma?

¿Qué sucede si los marcos de simulación ya no tienen que esperar un segundo entero para ser enviados?

¿Qué implicaciones tiene esto para la dilación del tiempo? ¿Cambia el metajuego cuando las batallas se libran en tiempo real y a gran escala?

Si la fidelidad de la red puede aumentar 90 veces, ¿qué nuevas experiencias pueden aportar los diseñadores a los pilotos de Nuevo Edén?

Estas son las preguntas que darán forma a la evolución de EVE Online, y algunas podrán tener respuesta en CCP TV el 20 de febrero a las 15:00, así que no olvides sintonizarnos.

o7