Cuál es el quid de Apex: Un desarrollador profundiza en los servidores y el «netcode»

Hola, soy @ricklesauceur, ingeniero jefe de Apex Legends y hoy quiero darles un poco de información sobre la infraestructura online que respalda a Apex Legends.

En el pasado, no solíamos hablar públicamente sobre los servidores, el «netcode» o la infraestructura online de Apex Legends, y hoy queremos comenzar a cambiar eso. En resumen, hoy queremos hacer lo siguiente:

• Compartirles un poco de información sobre cómo estamos trabajando para mejorar su experiencia online en Apex Legends
• Reconocer y explicar algunos de los problemas online más comunes o problemas de conectividad que podrían encontrar al jugar a Apex
• En especial, abordar preguntas frecuentes sobre temas como servidores en cámara lenta, el registro de los impactos y cómo funciona nuestro sistema de compensación de retardos.
• Darles datos concretos sobre la tasa de actualización del servidor y explicarles lo que pensamos sobre los efectos que tiene y los que no tiene.

Advertencia: esta publicación es larga porque queremos hacer un verdadero análisis de la infraestructura online de Apex Legends, algo que los jugadores nos piden hace mucho tiempo. 

Creemos que esto es el punto de partida de un debate más largo, así que, aunque abarcaremos mucho terreno aquí, probablemente haya muchos temas (ataques DDOS, fallos en el servidor, etc.) a los que podríamos dedicarles más tiempo. Sea como sea, si les late este blog, cuéntennos qué les gustaría saber la próxima vez, y seguiremos debatiendo con ustedes.

¡Damos la bienvenida a quienes les entusiasme hablar sobre netcode, los servidores, tasas de actualización y más! Empecemos hablando de algunas mejoras recientes que hemos implementado.

En la temporada 6, presentamos la visualización del rendimiento. Tiene esta apariencia y proporciona información básica sobre su rendimiento.

«In» y «Out» son el ancho de banda que consume el juego (en kB/s). También tienen latencia (en milisegundos). La pérdida de paquetes («packet loss») y el límite de paquetes («packet choke») se renderizan como un porcentaje de paquetes por segundo.

Esas cifras los ayudan tanto a ustedes como a nosotros a comprender lo que están experimentando mientras juegan. En otras palabras, podemos traducir lo que sienten en información técnica e información con la que podemos hacer algo.

Antes de esta implementación, los jugadores nos decían que había un problema con «algo», pero no siempre podían darnos más información. Ahora, podrán informarnos con precisión de cosas como: «Tengo un 10 % de pérdida de paquetes, 300 ms de latencia», etc. Esto lo cambia todo, porque esos números suelen ser la mejor indicación de lo que va mal. Regresaré a este punto.

Mientras trabajábamos en la visualización del rendimiento, también comenzamos a hacer un seguimiento de las métricas de rendimiento clave de jugadores y servidores. Esto significa que, si reporta un problema, nosotros podemos tomar su partida y ver los datos de todos los jugadores de la partida en ese momento, incluida información sobre el servidor específico que alberga el juego. 

Esto representó nuestro primer gran empujón para dar a nuestro equipo medios de investigación personalizados y dedicados. Hemos tenido bastante éxito con este enfoque, pero creemos que a largo plazo no evolucionará bien. Primero, tenemos que oír sus opiniones, luego enviar a un ingeniero para ver de dónde se origina el problema y después (dependiendo de dónde se encuentra el problema), intentar solucionarlo.

En las temporadas más recientes, comenzamos a aprovechar la ayuda de nuestro increíble equipo de «data science» para procesar los datos, es decir, recopilar y analizar una semana de datos cada vez para detectar la pérdida excesiva de paquetes y problemas de rendimiento de los servidores. Esta metodología ya dio frutos. Por ejemplo, descubrimos que un equipo de red en nuestro centro de datos tenía errores, lo que provocaba que todas las partidas alojadas en algunos servidores tuvieran rendimientos de red horribles. El servidor en sí mismo estaba bien, pero el hardware que conectaba a los jugadores con los servidores en cuestión estaba causando una pérdida enorme de paquetes. Encontramos muchos ejemplos como este.

El principal beneficio que tenemos al analizar datos es que nos permite cruzar parámetros de referencia y jugadores para encontrar patrones. Así que, semana a semana, podemos definir con seguridad si la salud de nuestra flota de servidores es mejor o peor. El análisis de datos también es una gran herramienta para ayudar a nuestros socios a solucionar problemas cuando se trata de algo que escapa a nuestro control. En lugar de decir que algo está mal, podemos decir que «esta cuestión específica está mal», algo que permite ahorrar tiempo a todas las personas involucradas. (Por cierto, si lo desean, pueden cancelar esta opción. Solo tienen que ir a «Jugabilidad» y luego a «Compartir uso» en el menú de configuración.) 

Por lo tanto, la automatización ayuda mucho. Pero no lo suficiente. 

Con esta metodología, nuestra capacidad de reacción a los problemas aún es lenta. Tenemos que esperar una semana para recopilar la mayoría de los datos y recibir los informes de manera confiable, de modo que normalmente tenemos que tomarnos otra semana para realizar una investigación completa. Desde el momento en que ustedes comienzan a descubrir problemas, nosotros podemos llegar a tomarnos hasta dos semanas para encontrar una solución y mucho tiempo más para implementarla, en caso de que necesitemos implementar un parche en el servidor.

Podemos hacerlo mejor. Lo haremos mejor. Así que hablemos de soluciones.

En primer lugar, además de nuestro informe semanal, apostamos por las alertas en tiempo real. Con ellas, obtendremos el mismo nivel de información que tenemos ahora, pero más rápido. Podremos solucionar problemas de hardware enseguida o comenzar a investigar y trabajar en un parche. Entendemos la frustración de tener que esperar mucho tiempo y estamos tratando de reducir el tiempo que transcurre entre una alerta y su solución.

En segundo lugar, vamos a implementar un nuevo ID único de servidor («SID») a la visualización de rendimiento que nos permitirá encontrar el servidor en el que están jugando más rápido. Actualmente, ustedes nos dan una hora y una fecha, y nosotros relacionamos esa información con los datos que tenemos sobre ustedes para encontrar el servidor en el que estaban jugando. Pronto podremos dejar de hacerlo. 

Esperamos que las dos soluciones mencionadas empiecen a estar disponibles en la próxima temporada: Apex Legends: Legado. El resultado para los jugadores será una resolución más rápida de los problemas de los servidores, a veces el doble de rápida.

Ahora, vamos a la parte divertida, vamos a categorizar onlines generales los problemas de servidor con los que podrían encontrarse. La lista que verán a continuación no está completa, pero espero que responda la mayoría de sus preguntas.

El servidor se ejecuta en cámara lenta.

A todo el mundo le encanta este. Nuestros servidores se ejecutan a 20 Hz. Esto significa que simulan el estado de todo el mundo una vez cada 50 ms (1 segundo o 1000 ms, divididos entre 20).

No hablamos de FPS (fotograma por segundo) cuando hablamos del rendimiento del servidor, porque un servidor no muestra imágenes. En su lugar, un servidor calcula «estados», pero el principio básico es el mismo. Necesita entradas del usuario (desde la red), ejecuta la física, envía el nuevo estado del mundo a los clientes y, luego, repite todo eso. Si este proceso toma más de 50 ms de forma consistente, su partida se ralentizará para permitir que el servidor termine la simulación. Por lo tanto, los servidores andarán en cámara lenta.

Vista del tiempo por fotograma de un servidor. La columna 5 es el objetivo de 50 ms. Todo lo que está debajo es más rápido. Aquí pueden ver que este servidor era estable y más rápido de lo necesario.

En comparación, este servidor nunca alcanzó el tiempo de fotogramas y la mayor parte del tiempo funcionó a 200 ms (4 veces más lento). Por lo general, así se comporta un servidor en cámara lenta.

Hay varias cosas que pueden provocar esto, pero a veces está relacionado con las máquinas del centro de datos, que no están funcionando como deberían. Piensen en una CPU «underclockeada», sobrecalentada, etc. 

Cuando las detectamos ese tipo de CPU, solemos eliminarlas. Esto significa que llamamos literalmente al proveedor de servicio, indicamos el problema con la máquina y le pedimos que la desconecten. 

La solución de detección en tiempo real mencionada anteriormente en este blog debería reducir este problema de forma considerable tan pronto lo publiquemos durante la próxima temporada. Estamos invirtiendo muchísimos recursos para resolver este problema, así que vamos a vigilarlo de cerca.

Mi latencia sube y baja.

Si juegan en una red wifi, ¡no podemos ayudarlos mucho! Si ese no es el problema, un nivel muy cambiante de latencia, a veces, puede estar relacionado con el rendimiento de nuestro servidor.

Todos sabemos que, incluso si un juego suele jugarse a 60 FPS, todo puede cambiar cuando hay muchas cosas en pantalla. Aunque solo estén perdiendo algunos fotogramas, lo notarán. Con los servidores, funciona de forma similar. Aquí, la detección automática no ayuda mucho a determinar la causa principal del problema. Históricamente, tuvimos que recrear las condiciones de la ralentización en un servidor de desarrollo, pero esta opción consume bastante tiempo y siempre es como ir dando pasos a ciegas: su máquina probablemente no funcione en el mismo hardware o con los mismos ajustes, así que es difícil replicar todo a la perfección.  

Afortunadamente, nuestro equipo de operaciones produjo una herramienta que nos permite obtener un archivo llamado RPROF. Básicamente, este archivo es una imagen de lo que hace el servidor durante cada fotograma (simulación balística, entrada y salida de red, movimientos del jugador, etc.). Gracias a los archivos RPROF, podemos descubrir cuál es la causa de la ralentización y un ingeniero puede comenzar a optimizarlo. Normalmente, el problema tiene que ver con el aumento de la demanda de rendimiento que presentan las nuevas características, temporada tras temporada. 

Puede que recuerden, por ejemplo, la ralentización en la pantalla de los campeones al inicio de las partidas durante las temporadas 7 y 8. El problema era que todos los jugadores de la partida aparecían en el mismo lugar, unos encima de otros, e incluso se superponían entre sí. (¡Y ni siquiera podían verlos por culpa de la IU!). Las simulaciones de física detestan que algunos objetos se superpongan a otros y nuestro motor de física intentaba alejar todos los cuerpos, algo que provocaba picos masivos de la CPU en el servidor.

Porcentaje de partidas afectadas por un servidor con rendimiento lento (no necesariamente en cámara lenta) por regiones. Pueden ver que algunas regiones mejoran con el tiempo y otras todo lo contrario (el eje X es el tiempo).

Una vista detallada de la región oeste de EE. UU. que nos permite detectar máquinas con fallos (el eje X es el tiempo). Los cortes de energía son muy claros en los gráficos. Algunas máquinas se ven afectadas, pero otras siguen estables.

Anticipamos que el uso de los archivos RPROF nos ayudará a optimizar las nuevas funciones que agregamos al juego y a reducir la latencia en general de cara al futuro. Reducir la latencia de todos los jugadores es un gran objetivo para nosotros y las buenas herramientas como esta son cruciales para ayudarnos a cumplir nuestro objetivo. 

Tengo muchas pérdidas de paquetes/límites de paquetes.

Esto es extremadamente complicado. Probablemente no sea culpa de ustedes, ¡y normalmente tampoco es nuestra! 

Tiene que ver con la forma en la que viaja el tráfico de Internet de su PC al centro de datos y vuelve hacia ustedes. Al principio, su tráfico de red está en tu red de ISP. Su ISP podría estar sufriendo alguna interrupción y, en ella, su información, junto con la información de otros clientes, se perdería. Como consecuencia, el cliente del juego no sabría qué está sucediendo con los jugadores que les rodean o el servidor del juego no sabría que ustedes quieren disparar sus armas o moverse en una dirección determinada. También está la conexión entre la red de su ISP y la red de nuestro centro de datos. En todo este trayecto, se pueden dar muchísimos problemas.

Cuando todo funciona sin problemas, llamamos a este proceso «emparejamiento». La mayoría de las veces, los problemas de emparejamiento aparecen cuando la conexión entre dos redes tiene un enlace débil. En el camino, pueden producirse varios saltos como este. Y luego, por supuesto, toda la información de los servidores de Apex necesita volver hacia ustedes, a menudo por medio de una ruta diferente. Pueden comenzar a entender por qué esto se vuelve complejo. 

Si queremos ayudarlos a resolver este tema, lo primero que debemos hacer es ser capaces de detectar dónde está el apagón. Esto es difícil de automatizar, porque necesitamos datos de ustedes y del servidor  a fin de poder investigar el problema desde ambas «perspectivas» e intentar rastrear el camino para ver dónde está el problema. 

Actualmente, les pedimos a los jugadores que nos den algún tipo de rastro de red y nosotros hacemos lo mismo desde el centro de datos para intentar detectar dónde está la zona de congestión. Esta metodología consume mucho tiempo y es lenta a la hora de resolver el problema, porque, dependiendo de nuestros descubrimientos, tenemos que negociar con diferentes socios comerciales de todo el mundo. Esperamos que la automatización nos ayude a mejorar este proceso y estamos pensando en algunas mejoras que aún están en etapas tempranas de desarrollo. 

En lo relativo a problemas de tráfico en la red como de los que estamos hablando, lo bueno es que los problemas suelen producirse en grupo en lugar de estar vinculados a una persona en particular. Esto significa que, normalmente, la corrección del problema de un jugador afectado desbloquea muchos otros. También estamos reduciendo activamente el ancho de banda que utiliza el juego, algo que ayuda a mitigar el problema.

Esto es un rastro de red (que muestra la latencia) de uno de nuestros jugadores profesionales desde su módem de Internet a uno de nuestros servidores. Hicimos varios análisis para evaluar el verdadero estado de la conexión a Internet. Verán que disfruta del juego en el mejor estado con una latencia de 31 ms. Pero la peor latencia llega a 522 ms. Así que, en este caso, su experiencia de juego es extremadamente mala, ya que su conexión oscila con una diferencia de 500 ms. La conexión es un poco temblorosa en su red local de ISP, pero el promedio nos muestra que es bastante rara (el promedio es de 31 ms, con un pico malo de 264 ms, que debe ser un incidente aislado). Pero luego vemos un aumento de la latencia entre el ISP local y el ISP1, que es uno de los nodos entre el jugador y nuestro servidor de juego. Podemos estar prácticamente seguros de que hay problemas de pérdida de paquetes y de enrutamiento entre los dos. Esto es algo que está fuera de nuestro control, pero podemos reportar el problema a esos asociados. Normalmente, todo el mundo está interesado en resolver los problemas.

Me matan mientras estoy detrás de una puerta/pared y, a veces, vuelvo a mi posición anterior.

Este es un tema complicado. Tiene que ver con la compensación del retardo. 

En todos los juegos, desde los albores de los juegos online, el principal problema que deben resolver los desarrolladores es cómo simular acción en tiempo real en algo que no funciona en tiempo real. Básicamente, todo lo que hacen los juegos online está retrasado por la latencia que hay entre el servidor y la vuelta. Muchas cuestiones se suman a todo esto: entradas, renderizado y sí, incluso la tasa de actualización. 

Y, lo que es aún peor: también está su rival, que seguramente juega con un nivel de latencia diferente al de ustedes. Para resolver esto, nuestros servidores no solo tienen que analizar constantemente lo que está sucediendo en su PC y la de su rival de ese momento, sino también lo que estaba sucediendo desde ambas perspectivas al momento en que ambos ustedes realizaron sus acciones. La compensación de retardo es el arte de fusionar experiencias ligeramente diferentes en una realidad compartida. 

No hay una solución perfecta. No hay una verdad absoluta. Al fin y al cabo, el servidor es una especie de máquina del tiempo. Retrocede constantemente el estado del mundo para ver si su disparo impactó en alguien y luego actualiza el mundo de todos en función a eso. 

Para ilustrar mejor este principio, mi colega Earl Hammon escribió un pequeño artículo sobre la imparcialidad y la compensación del retardo, y sobre cómo funciona todo esto en Apex Legends. Se lo comparto a continuación:

Veamos varios escenarios con dos jugadores en Apex Legends llamados ALTO y BAJO. Vamos a darle a ALTO un ping alto de 300 ms y a BAJO, un ping bajo de 50 ms. La diferencia entre sus pings es de 250 ms.

¿Qué sucede si se disparan uno a otro al mismo tiempo en el mundo real? Bueno, el disparo de BAJO llegará al servidor mucho antes que el disparo de ALTO, así que BAJO tiene ventaja.

¿Qué ocurre si uno de ellos dobla en una esquina y, de pronto, se pueden ver el uno al otro? Bueno, BAJO también tiene la ventaja. BAJO está menos «dentro del pasado», así que puede ver a ALTO primero. Una vez más, BAJO tiene ventaja debido a su ping. Esto se suma a la ventaja de que las balas de BAJO llegan más rápido al servidor.

Estos casos son «injustos», porque BAJO tiene una ventaja, pero son «justos» porque es razonable esperar que el jugador que tenga menos ping tenga ventaja en esta situación.

Ahora, ¿qué ocurre si BAJO intenta esconderse detrás de una esquina? Bueno, ALTO todavía está en el pasado cuando BAJO no está cubierto, así que ALTO puede disparar a BAJO antes de que llegue a su zona de cobertura, pero BAJO no se enterará hasta que los paquetes de ALTO hayan llegado al servidor y luego a BAJO. Para cuando eso suceda, BAJO verá que está sano y salvo, aunque BAJO igual recibirá el impacto. Desde el punto de vista de BAJO, esto no tiene ningún sentido.

Sin embargo, ¡esto es exactamente lo mismo que pasó con algunos de los primeros sinsentidos que favorecieron a BAJO antes! Cuando BAJO sale de su cobertura para atacar a ALTO, BAJO puede ver y disparar a ALTO, mientras que a ALTO aún no ve que BAJO está a cubierto. Desde el punto de vista de ALTO, esto no tiene sentido... ¿Cómo puede ser que le dispare alguien que todavía estaba cubierto? Este sinsentido no se puede eliminar; solo se transfiere entre un jugador u otro, debido simple y llanamente a que el ping es real y los jugadores tienen distintas cantidades de este. 

Algunos dirán que es injusto para BAJO que ALTO le pueda disparar cuando BAJO cree que está a cubierto. La alternativa que sugieren es que ALTO debería tener que hacerse cargo de su ping. Para garantizar esta solución, deberíamos implementar una forma desigual y asimétrica de controlar la latencia. 

Es horrible que te disparen cuando crees que estás a cubierto por culpa de un mal ping, que es lo que puede sucederle a BAJO. También es horrible que alguien te dispare antes de que puedas verlo por el mal ping, que es lo que le sucede a ALTO. Pero el sinsentido se distribuye simétricamente.

Queremos ser muy claros: no todos los juegos online funcionan de la misma forma que Apex. Algunos juegos siempre dan ventaja a los jugadores con menor ping, pero nosotros elegimos conscientemente hacer algo distinto con nuestro sistema. Es una postura que tomamos intencionadamente después de sopesar las compensaciones y de plantearnos seriamente la imparcialidad de las competencias online. 

Para explicar nuestro sistema en términos simples, los jugadores con ping bajo no siempre tienen ventaja sobre los jugadores con ping alto, y a veces se topan con un poco de sinsentido (para nosotros, ese es un término técnico). 

Es una compensación diseñada deliberadamente en nuestro sistema. Pero la ventaja es que pueden jugar a Apex Legends y jugar relativamente bien aunque tengan una latencia superior a la media, algo realmente importante para jugadores que viven en regiones rurales o en regiones donde la conectividad es inestable. Creemos que debemos reducir el «sinsentido» siempre que podamos, pero, a la hora de lidiar con experiencias que no son las ideales, queremos hacerlo de forma igualitaria y justa para todos los jugadores.

Esta es la razón por la que casi siempre que se topan con un poco de sinsentido, como cuando les disparan detrás de una pared o cuando los alcanzan justo después de doblar una esquina, probablemente se deba a variaciones inevitables de latencia entre los jugadores y la forma en que el sistema la distribuye. De todas formas, nos comprometemos a reducir estas situaciones siempre que podamos. No solo queremos que todos tengan una experiencia justa, sino que también queremos que se diviertan.

Algunos de mis disparos no se registran.

Hablemos sobre el registro de los disparos. Un disparo sin registro es un disparo en el que creen que golpearon al objetivo, pero el servidor no estuvo de acuerdo. Desde su perspectiva, tienen todo tipo de confirmación: ven que sale sangre del enemigo y escuchan el sonido del impacto. Sin embargo, el contador de daño no aparece. En un juego de disparos como Apex Legends, esto es sumamente desagradable. 

Puede deberse a muchos motivos. A veces, la latencia alta o la pérdida de paquetes pueden provocar que su simulación local sufra una desincronización con el servidor. Dispararon donde vieron a un enemigo, pero en realidad dispararon donde el enemigo había estado antes. Lamentablemente, no se darán cuenta hasta que su versión del mundo llegue a ese momento.

A veces, es solo un error en la simulación de la física del juego. Para ofrecerles una reacción al instante, nos basamos en un concepto llamado «predicción». Cuando disparan, sabemos cuál es el proyectil del arma, así que podemos predecir hacia dónde va la bala a nivel local sin necesidad de que el servidor se lo diga. Esto hace que el juego responda mejor. 

Normalmente, el cliente y el servidor coinciden, y las balas van donde se predice. En el pasado, tuvimos algunos errores de computación de la balística y la trayectoria de las balas (para todas las armas cuyo tamaño de bala que no era un punto, como los rifles de francotirador, por ejemplo). Estos errores pueden ser complicados de detectar, así que colocamos un elemento visual en nuestras pruebas para ayudar a los jugadores a detectar el problema al momento. Por desgracia, este código de diagnóstico es demasiado pesado para ejecutarse en el juego en vivo (debido a problemas de ancho de banda), por lo que solo podemos confiar en nuestras pruebas internas.

Cada vez que se produce un impacto sin registro, dibujamos el recuadro de impactos («hitbox») y la trayectoria de la bala (aproximadamente, la trayectoria debería doblarse un poco, ¡pero no está nada mal!). Es una ayuda visual para descubrir qué sucedió y poder realizar una búsqueda en nuestros registros del servidor.

Hay dos formas en la que estamos progresando:

La primera es buscar constantemente los diferentes errores que dan como resultado problemas de detección de impactos. También estamos desarrollando herramientas para automatizar la detección y ayudar a los desarrolladores a evitar que se presenten nuevos errores. Será un esfuerzo constante y continuo de nuestra parte.

¡La segunda es trabajar con ustedes! Cuando los jugadores nos envían videos de problemas de detección de impactos en el momento en que se producen, nos ayudan a descubrir si hay un error que debemos solucionar. A menudo, nos damos cuenta de que los clips que nos envían están relacionados con un problema de latencia en lugar de con un problema de detección de impactos, así que no se olviden de verificar la visualización de su rendimiento antes de reportar un problema con el registro de impactos. Sin embargo, como mencionamos anteriormente, hemos encontrado y resuelto errores de esta manera en el pasado, por lo que los reportes pueden ayudarnos a mejorar el juego para todos. ¡Gracias de antemano!

¿Qué pasa con los errores que no me permiten iniciar sesión, como «code:net»?

«Code:net» es un mensaje de error genérico que aparece en el juego cuando se agota el tiempo de espera de su partida en el servidor. Esto puede estar relacionado con varios problemas, tanto nuestros como de ustedes. De hecho, descubrimos que algunos de los errores más graves relacionados con «code:net» (y errores relacionados, como «code:leaf», etc.) podrían tener más que ver con los servicios de Respawn que dan soporte al juego y habría que investigarlos.

Hemos tomado una serie de medidas para reducir la probabilidad de que se produzcan errores de «code:net», y muchos jugadores podrán resolver su situación luego de contactar con nuestro equipo de asistencia. Si no pueden iniciar sesión y reciben el mensaje «code:net» u otro parecido, por favor, repórtenlo desde el sitio de ayuda de EA.

Dado que «code:net» es un mensaje genérico, es posible que haga referencia a una serie de problemas distintos. En las últimas semanas, tuvimos mucho éxito en la resolución de algunos de estos problemas, pero sabemos que nos falta mucho por hacer. Cuéntennos los problemas y nosotros haremos todo lo posible para solucionarlos cuanto antes. Créannos cuando les decimos que odiamos este error tanto como ustedes.

Es hora de hablar del pez gordo. Queremos abordar el tema de forma transparente. Muchos jugadores nos preguntaron sobre la tasa de actualización del servidor y por qué no aumentamos la cifra de 20 Hz como lo hacen otros juegos de disparos online. 

Hemos explicado cómo la tasa de actualización afecta la frecuencia de actualización general de lo que se ve en pantalla, por lo que esta pregunta es totalmente válida. Sin embargo, comparar la tasa de actualización de un juego con la de otro es más complicado de lo que parece. Intentaremos explicarles por qué. 

La tasa de actualización de un servidor es la cantidad de simulaciones que ejecuta el servidor por segundo. Es un número fijo (consulten la sección sobre la cámara lenta). Apex utiliza un modelo de reproducción basado en instantáneas. Esto significa principalmente que, al final de cada actualización, el servidor guarda el estado del mundo y lo replica a todos los clientes. Este proceso incluye mucha información que permite que el diseño de nuestras armas, mapas y leyendas tenga la máxima fidelidad. 

Para tener éxito en Apex Legends, deben prestar atención a un chorro de información que se produce en todo el mapa. Usar habilidades tácticas, activar habilidades pasivas o habilidades definitivas, la llegada de paquetes de suministro al mapa o un nuevo escuadrón que ingresa al radio de alcance del dron de Crypto. No queremos que los jugadores se pierdan nada. Y nuestros diseñadores son capaces de crear juguetes y herramientas que pueden ser de naturaleza global. Muchos juegos no computan estados del mundo completo en cada actualización, lo que hace que sea erróneo intentar comparar un juego con otro según una sola cifra como «20Hz» frente a «30Hz». 

La pregunta es: ¿Qué sucede exactamente durante cada actualización? Queremos que el estado del mundo sea lo más preciso posible. Por eso, nuestros servidores guardan el estado del mundo completo en cada actualización. Si no lo hiciéramos, posiblemente ahorraríamos parte del costo de la CPU en nuestros servidores, pero perderíamos precisión en las simulaciones y no vale la pena arriesgarse a eso. 

En pocas palabras, cuanto mayor sea la tasa de actualización, mayor será el ancho de banda que se envía a todos los jugadores. Si nos pasáramos de un servidor de 20 Hz a un servidor de 60 Hz, estaríamos multiplicando por tres el ancho de banda que se usa el juego. En la actualidad, Apex Legends consume aproximadamente 60 kB/s al inicio de una partida. Un servidor de 60 Hz consumiría 180 kB/s. Puede que no parezca mucho, pero en realidad el cambio es bastante importante y siempre estamos buscando formas de reducir el ancho de banda necesario. 

Pero ¿por qué tendría importancia que el ancho de banda fuera un poco mayor? Mantener los costos de ancho de banda bajos para los juegos es mucho más importante que, por ejemplo, para la transmisión de videos. Para aplicaciones de alto ancho de banda (transmisión, descarga, etc.), las fluctuaciones o los problemas son fáciles de ocultar mediante el almacenamiento en un búfer de algunos minutos de la transmisión, la reducción de la calidad de la transmisión, etc. Es probable que no vean fluctuaciones en una descarga, y probablemente no les importe que la velocidad varíe entre unos cuantos o cientos de milisegundos. 

Los juegos no pueden darse este lujo. Saltarse, aunque sea un par de intervalos de 50 ms, puede empezar a dar una mala sensación. Si saltan algunos más, es posible que entren a un espiral letal que provocará que tengamos que enviarles actualizaciones cada vez más grandes para que puedan recuperarse. Y esas actualizaciones deberán ser imperativas, porque su cliente necesita un estado del mundo perfecto para ser preciso.

El ejemplo anterior muestra que comparar la tasa de actualización entre partidas es complicado, porque la información incluida en cada actualización varía. Otra complicación también es que los límites de las entradas que reciben y envían los servidores no siempre son los mismos, aunque tengan la misma tasa de actualización. En concreto, en muchos juegos, si un servidor funciona a 60 Hz, significa que el cliente solo puede enviar entradas de 60 Hz. Si se ejecuta a 60 FPS, está bien, pero si el cliente se ejecuta a 120 FPS, se perderían la mitad de las entradas. Este no es el caso de Apex Legends. Nosotros procesamos bien la velocidad variable de las entradas. (Como nota aparte, mientras más alto sea su valor de FPS en Apex, mayor será el uso del ancho de banda).

Ya hemos hablado de los posibles inconvenientes que acarrea el aumento de la tasa de actualización del servidor. Pero ¿qué hay de las ventajas de pasar de 20 Hz a 60 Hz? ¡Vamos, Respawn! ¿Eso no haría que los servidores se volvieran tres veces más rápidos y mejores? ¡Háganlo y ya!

Según nuestros descubrimientos, eso no cambiaría mucho la experiencia y queremos explicarles por qué. 

Por poner un ejemplo, digamos que juegan con un promedio de 50 ms de ping, o latencia. Recuerden que el ping mide la velocidad de un viaje de ida y vuelta entre su máquina y el servidor. Por lo tanto, siempre que no haya otros problemas, como latencia fluctuante o retardos del hardware (por ejemplo, los dispositivos de visualización presentan un retardo de 20-50 ms), el servidor recibirá su entrada 25 ms (medio ping) después de pulsar un botón o mover el mouse. 

Como nuestros servidores son de 20 Hz, actualizan el estado del mundo cada 50 ms (1000 ms por segundo /20 actualizaciones por segundo = 50 ms por actualización). Así que, en el peor de los casos, el servidor procesará sus entradas luego de 75 ms (25 ms + 50 ms). 

Para saber qué significa realmente el retardo de 75 ms en términos de experiencia, deben pensar en su frecuencia de fotogramas. El cálculo aquí puede complicarse un poco, pero recuerden que, en un juego de 60 FPS, cada fotograma toma unos 16,67 ms (1000 ms por segundo / 60 fotogramas por segundo = 16,67 ms por fotograma). Si el servidor procesa sus entradas luego de 75 ms, como en nuestro ejemplo anterior, y su juego se ejecuta a 60 FPS, eso significa que el retardo entre su entrada y su efecto en el juego es de unos cinco fotogramas (75 ms por cada actualización / 16,67 ms por fotogramas = unos 4,5 fotogramas, y se redondea a 5 fotogramas, ya que no existen los «medios fotogramas»). 

Si realizan los mismos cálculos en un servidor de 60 Hz, obtienen 41,67 ms de retardo máximo entre la entrada y el servidor que lo procesa (25 ms de ping + [1000 ms / 60 actualizaciones por segundo = 16,67 ms por actualización] = 41,67 ms). 

41,67 ms es definitivamente mejor que 75 ms, pero, ¿qué problema puede haber para la tasa de fotogramas? Pongamos por caso de nuevo que estamos ejecutando el juego a 60 FPS. Cada fotograma toma 16,67 ms, así que ahora el retardo entre las entradas y el servidor que las reconoce es de tres fotogramas (41,67 ms por cada actualización / 16,67 ms por fotograma = unos 2,5 fotogramas, que se redondea a 3 fotogramas, ya que no existen los «medios fotogramas»). 

Si juntamos todos estos números, nos daremos cuenta de que los servidores de 20 Hz tienen como resultado unos cinco fotogramas de retardo y los servidores de 60 Hz tienen como resultado tres. Por lo tanto, si triplicamos el ancho de banda y del costo de la CPU, podemos ahorrar dos fotogramas de latencia, en el mejor de los casos. La ventaja es esa, pero no es enorme y no serviría de nada para resolver los problemas relacionados con el viejo retardo de siempre (como recibir disparos mientras están a cubierto), los problemas de ISP o distintas fallas (como los registros de impactos y los servidores en cámara lenta). 

En nuestro ejemplo, examinamos la ventaja de pasar de 20 Hz a 60 Hz. Pueden hacer los cálculos para otros saltos, como de 20 Hz a 30 Hz o incluso 40 Hz, y verán que las ventajas para la frecuencia de fotogramas por segundo tampoco son significativas. Tendrían que aumentar la tasa de actualización de forma muy drástica para poder ver un cambio de verdad; incluso el paso de 20 Hz a 60 Hz sería como la diferencia que hay entre 58 FPS y 60 FPS. No es que no haya diferencia, pero, sinceramente, creemos que no es suficiente para priorizar los cambios de tasas de actualización otras mejoras más eficientes en las que podríamos estar trabajando.

Para terminar, queremos hablar de la frustración real y genuina que sufren los jugadores por culpa de los problemas online. Tener que lidiar con retardos, con impactos sin registro o con servidores en cámara lenta es horrible. Atenta contra la inmersión en la partida y puede ser algo muy desmotivador cuando se esfuerzan para subir de rango, cuando intentan realizar una jugada magistral con sus compañeros de equipo o cuando simplemente quieren jugar y relajarse en la noche. 

Parte del desafío de hablar de los problemas online es que, cuando comenzamos a explicar nuestros sistemas o nuestra postura con relación a problemas como la compensación por retardo o la tasa de actualización, los jugadores que solo quieren que el juego mejore pueden sentirse frustrados. Si tienen problemas con la latencia o experimentan errores que hacen que el servidor falle, problemas de cuentas dañadas o cualquier otro desafío que tengan que enfrentar mientras juegan a Apex Legends, probablemente no quieren saber qué no estamos haciendo. 

En última instancia, solo queremos mejorar el juego. Cuanto mejor sea la experiencia online para ustedes, más jugadores se unirán al juego y eso nos permitirá seguir haciendo el trabajo que amamos. 

Es por esto que, en este blog, hemos compartido una gran cantidad de mejoras en las que trabajaremos en un futuro próximo, entre las que se incluyen las siguientes:

• Utilizar alertas en tiempo real que nos permitirán identificar problemas y reaccionar más rápido
• Implementar herramientas para identificar servidores de modo que podamos eliminar y reemplazar servidores problemáticos rápidamente
• Hacer hincapié en servidores lentos; eliminar servidores problemáticos es uno de los pasos, pero nuestro objetivo es realizar modificaciones en el código para conseguir que esta situación sea mucho menos habitual
• Reducir la latencia y optimizar mejor las nuevas características
• Arreglar los fallos que producen impactos sin registro y crear herramientas automatizadas de detección que nos ayuden a evitar que aparezcan nuevos fallos

Pero queremos que sepan que estas no son las únicas cuestiones en las que estamos trabajando. Estamos trabajando con nuestros asociados de servidores e ISP para mejorar e invertir en nuestra infraestructura online con el objetivo definitivo de que los jugadores reporten cada vez menos problemas y para garantizar una mejor experiencia general. Nuestra intención es seguir hablando sobre estos planes en una próxima publicación, cuando comencemos a ver que nuestros esfuerzo dan frutos. 

Si empezamos a comunicarnos mejor con ustedes y a hablarles de los problemas que nos preocupan, comenzaremos a compartir conceptos para determinar las causas principales de los problemas que enfrentamos. Por eso escribimos esta publicación. Esperamos que este blog nos permita explicar nuestro razonamiento y desmitificar los tecnicismos de ejecutar un juego de disparos online. Y esperamos que sea el comienzo de más conversaciones futuras.

¡Gracias por leernos! 

- Samy (Ricklesauceur) y el equipo de Apex Legends

Juega Apex Legends gratis* ahora en PlayStation®4, PlayStation®5, Xbox One, Xbox Series X|S, Nintendo Switch y PC a través de Origin y Steam.

Sigue a Apex Legends en Twitter e Instagram, suscríbete a nuestro canal de YouTube y checa nuestros foros.

Suscríbete hoy a nuestro boletín de noticias para recibir las últimas noticias, actualizaciones, contenido entre bambalinas, ofertas exclusivas y mucho más de Apex Legends por correo electrónico (incluidas otras noticias, productos, eventos y promociones de EA).

Este anuncio puede cambiar. Escuchamos a la comunidad y el contenido y el servicio en vivo siguen desarrollándose y evolucionando. Siempre buscaremos que la comunidad esté tan informada como sea posible. Para más información, dirígete a la página de actualizaciones del servicio online de EA en https://www.ea.com/es-mx/service-updates.

*Puede requerirse una cuenta y una suscripción de la plataforma aplicable (se venden por separado). Requiere conexión a Internet estable y una Cuenta EA. Aplican restricciones de edad. Incluye compras en el juego.