Explicación de los desarrolladores de Apex sobre los servidores y el código de red

Hola, soy @ricklesauceur, ingeniero jefe de Apex Legends y vamos a comentar la infraestructura online que respalda a Apex Legends.

Hasta ahora no hemos hablado públicamente de servidores, código de red o infraestructura online de Apex Legends y queremos comenzar a hacerlo. En resumen, hoy queremos:

• Compartir información sobre cómo trabajamos para mejorar la experiencia online en Apex Legends
• Confirmar y explicar algunos problemas online comunes o problemas de conexión que puedes encontrarte al jugar a Apex.
• Abordar específicamente preguntas frecuentes sobre temas como servidores a cámara lenta, registro de impactos y cómo funciona nuestro sistema de compensación del retardo.
• Ofrecer unas notas exhaustivas sobre la frecuencia de actualización de nuestros servidores y explicar nuestra opinión sobre a qué afecta y a qué no.

Aviso: esta publicación es larga porque queremos que sea un análisis en profundidad de la infraestructura online de Apex Legends, algo que los jugadores llevan pidiéndonos mucho tiempo. 

Nos la planteamos como el punto de partida de una conversación más larga, así que, aunque cubramos bastantes cuestiones, probablemente queden muchos temas (ataque DDoS, errores que bloquean el servidor, etc.) que podríamos abordar más a fondo. Si te gusta este blog, indícanos sobre qué querrías que hablaramos la próxima vez y lo tendremos en cuenta.

Si estás listo para hacer el friki con el código de red, los servidores, la frecuencia de actualización y mucho más... ¡Te damos la bienvenida! Empecemos por las mejoras que hemos aplicado recientemente.

En la temporada 6, presentamos el indicador de rendimiento. Tiene el siguiente aspecto y proporciona información básica sobre el rendimiento.

«Dentro» y «fuera» indican el ancho de banda que consume el juego (en kB/s). También tienes la latencia (en milisegundos). Los paquetes perdidos y estrangulados se renderizan como porcentaje de paquetes por segundo.

Estas cifras te ayudarán (y a nosotros) a comprender lo que experimentas al jugar. En otras palabras, podemos traducir lo que se percibe en información técnica y útil.

Antes de esta incorporación, los jugadores nos indicaban que «algo» iba mal, pero no siempre podían darnos mucha más información. Ahora puedes decir con precisión «Tengo un 10 % de pérdida de paquetes, 300 ms de latencia», etc. Esto cambia todo porque estas cifras suelen ser la mejor indicación de lo que sucede. Luego regresaré a esta cuestión.

Mientras trabajábamos en el indicador de rendimiento, también empezamos a realizar un seguimiento de las métricas de rendimiento clave de jugadores y servidores. Esto significa que si alguien informa de problemas, podemos extraer la partida y ver los datos de todos en el juego en ese momento, incluida información sobre el servidor específico que aloja la partida. 

Este fue nuestro primer gran esfuerzo para ofrecer a nuestro equipo medios de investigación personalizados y específicos. Aunque este enfoque ha resultado positivo, creemos que a largo plazo, no será suficiente. Primero tenemos que recibir tu información y pedir a un ingeniero que estudie de dónde viene el problema y después (en función de dónde se encuentre el problema), intentar solucionarlo.

En las últimas temporadas, hemos empezado a aprovechar la ayuda de nuestro fantástico equipo de ciencia de datos para recopilar y analizar una semana de datos para detectar pérdidas excesivas de paquetes y problemas de rendimiento del servidor. Este enfoque ya ha dado sus frutos. Por ejemplo, descubrimos que un equipo de red de nuestro centro de datos estaba defectuoso y provocaba que todas las partidas celebradas en varios servidores tuvieran un rendimiento de red horrible. El servidor en sí estaba bien, pero el hardware que conectaba a los jugadores a los servidores en cuestión causaba una pérdida masiva de paquetes. Nos encontramos un montón de ejemplos de este tipo.

La principal ventaja que obtenemos de analizar los datos de forma sistemática es que nos permite hacer una referencia cruzada de métricas y jugadores para buscar patrones. Por tanto, semana a semana, podemos decir con seguridad si nuestra flota de servidores va mejor o peor. El análisis de datos también es una herramienta fantástica para ayudar a nuestros socios a solucionar problemas que están fuera de nuestro control. En lugar de decir que algo va mal, podemos decir que «esto en concreto está mal», lo que permite ahorrar tiempo a todos los involucrados. Por cierto, puedes rechazar esta opción si quieres. Solo tienes que ir a Mecánica de juego y a Intercambio de información de uso en el menú de configuración. 

Así, la automatización ayuda mucho. Pero no es suficiente. 

De hecho, con este enfoque, seguimos tardando un poco en reaccionar ante los problemas. En general, tenemos que esperar una semana para que los datos se recopilen de manera fiable y nos lleguen correctamente. A menudo, puede que nos lleve otra semana realizar una investigación completa. Desde el momento en que empieces notar problemas, es posible que tardemos hasta dos semanas en encontrar una solución e incluso más en implementarla si es necesario un parche de servidor.

Podemos hacerlo mejor. Lo haremos mejor. Vamos a hablar de las soluciones.

En primer lugar, además de nuestro informe semanal, hemos implementado las alertas en tiempo real. Nos dará el mismo nivel de información que tenemos ahora, pero más rápido. Podremos arreglar problemas de hardware de inmediato o empezar a investigar y trabajar en un parche. Entendemos la frustración que supone tener que esperar e intentamos reducir activamente el tiempo entre alerta y solución.

En segundo lugar, vamos a incluir un nuevo ID de servidor («SID») único en el indicador de rendimiento que nos permitirá buscar más rápido el servidor en el que juegas. En la actualidad, nos indicas una hora y una fecha, que relacionamos con los datos que tenemos sobre ti para buscar el servidor en el que estabas jugando. Pronto no tendremos que hacerlo. 

Esperamos empezar a implementar ambas soluciones durante nuestra próxima temporada: Legado. El resultado para los jugadores será una resolución más rápida de los problemas de los servidores, a veces del doble, que en la actualidad.

Ahora llega la diversión: vamos a categorizar en líneas generales los problemas de los servidores con los que te puedes topar. La siguiente lista no es exhaustiva, pero espero que responda a la mayoría de preguntas.

El servidor funciona a cámara lenta.

A todo el mundo le encanta esta cuestión. Nuestros servidores funcionan a 20 Hz. Esto significa que simulan el estado del mundo una vez cada 50 ms (1 segundo o 1000 ms dividido por 20).

Al hablar del rendimiento del servidor no indicamos fps (fotogramas por segundo) porque el servidor no muestra imágenes. En su lugar, un servidor calcula «estados», pero el principio subyacente es el mismo. Toma las entradas del usuario (desde la red), ejecuta la física, devuelve el nuevo estado del mundo a los clientes y después repite. Si este proceso tarda más de 50 ms de forma continua, el juego se ralentizará para permitir que el servidor termine la simulación. Así se obtienen servidores a cámara lenta.

Revisemos el tiempo entre fotogramas de un servidor. En la columna 5 se indica el objetivo de 50 ms. Todo número inferior será más rápido. Podemos ver que este servidor era estable y más rápido de lo necesario.

En comparación, este servidor no alcanzaba el tiempo entre fotogramas y se ejecutaba principalmente a unos 200 ms de tiempo entre fotogramas (así que 4 veces más lento). Esto es común en un servidor a cámara lenta.

Hay varias cosas que pueden causar este problema, pero a veces se vinculan a equipos del centro de datos que no funcionan como deberían. Puede tratarse de una CPU poco acelerada, sobrecalentada, etc. 

Cuando detectamos estos problemas, solemos eliminar esos equipos. Esto significa que llamamos (literalmente) al proveedor de servicios, señalamos el problema con el equipo en cuestión y les pedimos que lo desconecten. 

La solución de detección en tiempo real que hemos mencionado en este blog debería reducir considerablemente este problema cuando la implementemos durante la próxima temporada. Estamos empeñados en resolver este problema, así que vamos a estar muy atentos.

Mi latencia sube y baja.

Si juegas con Wi-Fi, ¡no podemos hacer mucho! En otros casos, un cambio rápido de latencia puede estar relacionado con el rendimiento del servidor.

Sabemos que, aunque un juego normalmente se ejecute a 60 fps, puede cambiar cuando suceden un montón de cosas en pantalla. Aunque solo falten algunos fotogramas, lo notas. Esto ocurre de forma similar en los servidores. Aquí, la detección automática no ayuda mucho a determinar la causa principal del problema. Anteriormente, teníamos que recrear las condiciones de la ralentización en un servidor de desarrollo, pero requería mucho tiempo y teníamos que dar palos de ciego. Es probable que tu equipo no utilice el mismo hardware del servidor o que no tenga los mismos ajustes, así que es difícil replicar a la perfección.  

Por suerte, nuestro equipo de operaciones ha elaborado una herramienta para conseguir lo que llamamos un archivo RPROF. Se trata básicamente una vista de lo que hace el servidor durante cada fotograma (simulación balística, red dentro y fuera, movimientos del jugador, etc.). Gracias a los archivos RPROF, podemos descubrir qué ralentiza las cosas para que un ingeniero pueda comenzar la optimización. En general, el problema tiene que ver con un aumento de la demanda de rendimiento que presentan las nuevas funciones que se incorporan en cada temporada. 

Puede que recuerdes, por ejemplo, la ralentización en la pantalla Campeón al principio de las partidas durante las temporadas 7 y 8. La causa era que todos los jugadores de la partida reaparecían en el mismo lugar, unos sobre otros y a veces, superpuestos. (¡Y ni siquiera se les podía ver por la IU!) Las simulaciones de física detestan que los objetos se superpongan a otros y nuestro motor de física intentaba separar todos los cuerpos, lo que provocaba enormes picos de CPU en el servidor.

Porcentaje de partidas afectadas por un servidor con rendimiento lento (no necesariamente a cámara lenta) por regiones. Podemos ver que algunas regiones mejoran con el tiempo y otras se degradan (el eje X indica tiempo).

Una vista detallada de la región occidental estadounidense que nos permite detectar equipos defectuosos (el eje X indica tiempo). Las interrupciones son muy evidentes en las gráficas. Algunos equipos se ven afectados mientras que otros permanecen estables.

Anticipamos que el uso que hacemos de los archivos RPROF nos ayudará a optimizar las nuevas funciones que añadamos al juego y a reducir la latencia de forma más general en el futuro. Para nosotros es muy importante reducir la latencia de todos los jugadores. Para ello, es crucial que haya mejores herramientas como esta. 

Tengo muchos paquetes perdidos/estrangulados.

Este es extremadamente complicado. ¡Probablemente no sea tu culpa y tampoco suele ser nuestra! 

Tiene que ver con la forma en la que el tráfico de Internet viaja desde tu equipo a nuestro centro de datos y de regreso hacia ti. Al principio, el tráfico de red está en la red de ISP. Tu ISP podría sufrir una interrupción en la que tu información, junto con la de otros clientes, se pierde. Esto hace que el cliente del juego no sepa qué pasa con los jugadores que te rodean o que el servidor de juego no sepa que quieres disparar o moverte en una dirección determinada. También existe la conexión entre la red del ISP y la red de nuestros centros de datos. Los problemas pueden surgir en cualquier punto de esta línea.

Cuando las cosas van como la seda, denominamos este proceso «emparejamiento». La mayoría de las veces, los problemas de emparejamiento se deben a que la conexión entre dos redes tiene un eslabón débil. Pueden surgir muchas cuestiones de este tipo por el camino. Y, por supuesto, toda la información de los servidores de Apex tiene que regresar a ti, normalmente mediante una ruta diferente. Ya empezamos a ver por qué se complica la cosa. 

Si queremos ayudar a resolver el problema, lo primero que tenemos que hacer es detectar dónde está la interrupción. Esto es difícil de automatizar porque necesitamos datos del jugador y del servidor  para poder investigar el problema desde ambas «perspectivas» e intentar investigar la ruta para ver dónde se reside el problema. 

Desde hoy, pedimos a los jugadores que proporcionen algún tipo de seguimiento de red y hacemos lo mismo desde el centro de datos para intentar detectar dónde está el punto de congestión. Esto consume muchísimo tiempo y es lento de resolver porque, en función de nuestros hallazgos, tenemos que negociar con distintos socios empresariales de todo el mundo. Esperamos que la automatización ayude a optimizar este proceso y tenemos algunas mejoras en fases iniciales. 

En lo que respecta a los problemas de tráfico en la red, como los que estamos comentando, lo bueno es que suelen producirse a granel en vez de estar relacionados con un individuo en concreto. Esto significa que resolver el problema de un jugador afectado normalmente desbloquea otros muchos. También vamos a reducir activamente el ancho de banda que el juego utiliza para mitigar el problema.

Se trata de un seguimiento de red (que muestra latencia) de uno de nuestros jugadores profesionales, desde su módem de Internet a uno de nuestros servidores. Lo estudiamos varias veces para evaluar el verdadero estado de la conexión a Internet. Podemos ver que disfruta del juego en las mejores condiciones, con una latencia de 31 ms. Pero la peor cifra son unos 522 ms. En este caso, la experiencia de juego es extremadamente mala porque su conexión oscila con una diferencia de 500 ms. La conexión es un poco inestable en la red local de su ISP, pero la media nos indica que es bastante raro (una media de 31 ms con un peor valor de 264 ms, debe de ser un incidente aislado). Sin embargo, vemos un pico de latencia entre el ISP local y el ISP1, uno de los nodos entre el jugador y nuestro servidor de juego. Podemos estar casi seguros de que hay problemas de pérdida de paquetes y enrutamiento entre ambos. Esto queda fuera de nuestro control, pero podemos informar a los socios del problema. Todos queremos resolver la situación.

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

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

En todos los títulos desde los inicios de los juegos online, el principal problema que deben resolver los desarrolladores es cómo fingir acciones en tiempo real en algo que no funciona en tiempo real. Básicamente, todo lo que haces en los juegos online se retrasa por la latencia hacia el servidor y de vuelta. Muchas cosas se suman a esto: entradas, renderizado e incluso la frecuencia de actualización de los servidores. 

Y lo que es peor, es fácil que tu rival juegue con un nivel de latencia diferente al tuyo. Para resolver esta cuestión, nuestros servidores tienen que estudiar constantemente no solo lo que os pasa a ti y a tu rival en ese momento, sino también lo que os estaba sucediendo desde ambas perspectivas en el momento en el que ambos introdujisteis vuestras acciones. La compensación del retardo es el arte de fusionar experiencias ligeramente diferentes en una realidad común. 

No existe una solución perfecta. No existe una verdad única. A fin de cuentas, el servidor es una especie de máquina del tiempo. Retrocede constantemente el estado del mundo para ver si tu disparo impacta en alguien y después actualiza el mundo para todos en consecuencia. 

Para ilustrar mejor este principio, mi colega Earl Hammon escribió un pequeño ensayo sobre compensación del retardo y ecuanimidad y cómo funciona todo en Apex Legends. A continuación lo comparto:

Vamos a repasar varias situaciones con dos jugadores de Apex Legends, que denominaremos 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 de pings es de 250 ms.

¿Qué ocurre si se disparan el uno al otro a la misma hora del mundo real? El disparo de BAJO llegará al servidor mucho antes que el disparo de ALTO, así que BAJO tiene ventaja.

¿Qué pasa si uno de ellos dobla una esquina y quedan frente a frente? BAJO también tiene ventaja en este caso. BAJO no está tan «en el pasado», por lo que puede ver a ALTO primero. Una vez más, BAJO tiene ventaja debido a su ping. Esto se añade a la ventaja que supone que las balas de BAJO lleguen más rápido al servidor.

Estos casos son «injustos», ya que BAJO tiene ventaja, pero son «justos» en el sentido de que es razonable esperar que el jugador con ping más bajo obtenga una ventaja en esta situación.

¿Qué pasa si BAJO se esconde tras una esquina para ponerse a cubierto? ALTO sigue en el pasado cuando BAJO no se ha cubierto, así que ALTO puede disparar a BAJO antes de que se cubra, pero BAJO no lo descubrirá hasta que los paquetes de ALTO hayan llegado al servidor y hayan regresado a BAJO. En este momento, BAJO ve que está a cubierto, pero le han alcanzado. Desde la perspectiva de BAJO, esto es una sinsentido.

Sin embargo, esto es completamente simétrico a algunos de los sinsentidos anteriores que favorecían a BAJO. Cuando BAJO sale de su escondrijo para atacar a ALTO, BAJO puede ver y disparar a ALTO mientras que ALTO ve que BAJO sigue a cubierto. Desde el punto de vista de ALTO, es un sinsentido que le dispare alguien que aún está a cubierto. Este sinsentido no se puede eliminar, solo se puede transferir de un jugador a otro debido a que el ping es real y los jugadores tienen distintas cantidades. 

Se podría decir que no es justo para BAJO que ALTO pueda dispararle cuando BAJO cree que está a cubierto. La alternativa que se sugiere es que ALTO compense su ping alto. Esto nos obligaría a aplicar una forma desigual y asimétrica de control de latencia. 

No nos gusta recibir un disparo si creemos que estamos a cubierto debido a un ping inadecuado, que es lo que puede pasarle a BAJO. Tampoco nos gusta que nos disparen antes de poder ver al atacante por un ping inadecuado, que es lo que puede pasarle a ALTO. Pero el sinsentido se distribuye de forma simétrica.

Queremos dejar muy claro que no todos los juegos online funcionan como Apex. Algunos siempre dan ventaja a los jugadores con ping más bajo, pero nosotros elegimos no hacerlo con nuestro sistema. Hemos adoptado esta postura tras estudiar los intercambios y reflexionar sobre la ecuanimidad en la competición online. 

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

Se trata de un intercambio que se ha diseñado intencionadamente en nuestro sistema. Lo positivo es que puedes jugar a Apex Legends y jugar relativamente bien incluso si tienes una latencia superior a la media, lo que es muy importante para los jugadores de zonas rurales o para aquellos de regiones en las que la conectividad es inestable. Creemos que deberíamos reducir los «sinsentidos» siempre que podamos, pero cuando tenemos que lidiar con experiencias poco ideales, queremos hacerlo de una forma igualitaria y justa para todos los jugadores.

Por ello, casi siempre que se trata de un sinsentido como que te disparen tras una pared o te impacten justo a la vuelta de la esquina, probablemente se deba a una inevitable variación de latencia entre los jugadores y a la forma en la que nuestro sistema la distribuye. Aun así, nos comprometemos a reducirla en todo momento. No solo queremos que todo el mundo tenga una experiencia justa, sino que también queremos que se diviertan.

Algunos de mis disparos no se registran.

Vamos a hablar del registro de impactos. Si un disparo no se registra, significa que crees que has alcanzado a un objetivo, pero el servidor no está de acuerdo. Desde tu punto de vista, recibes todo tipo de confirmación en forma de chorros de sangre y sonidos, pero no aparece ningún contador de daños. En un shooter como Apex Legends, esto es muy desagradable. 

Y puede ocurrir por multitud de razones. A veces, una latencia elevada o la pérdida de paquetes pueden hacer que la simulación local se desincronice levemente con el servidor. Tú has disparado hacia el lugar en el que has visto a alguien, pero en realidad lo has hecho al lugar donde estaba previamente. Por desgracia, no lo descubrirás hasta que tu versión del mundo se actualice.

A veces, se trata solo de un error de simulación de física del juego. Para enviarte informes instantáneos, nos basamos en un concepto denominado predicción. Al disparar, conocemos la balística del arma, por lo que podemos predecir hacia dónde irá la bala sin necesidad de que el servidor nos lo diga. De esta forma, tenemos la sensación de que el juego responde mejor. 

Normalmente, el cliente y el servidor coinciden y la bala va donde se preveía. En el pasado, hemos tenido algunos errores en la forma de computar la balística y las trayectorias del proyectil (para todas las armas cuyo tamaño de bala no era un punto, como los rifles de francotirador, por ejemplo). Puede resultar complicado detectar este tipo de error, así que hemos establecido un elemento visual en nuestras pruebas de juego para ayudar a que la gente detecte el problema de inmediato. Por desgracia, este código de diagnóstico es demasiado pesado para ejecutarlo en el juego en directo (por cuestiones de ancho de banda), por lo que solo podemos utilizarlo en nuestras pruebas internas.

Cada vez que un impacto no se registra, dibujamos el área de impacto y la trayectoria del proyectil (de forma aproximada, ya que la trayectoria debería inclinarse un poco, pero es una buena aproximación). Se trata de una ayuda visual para que sepamos qué ha sucedido. También nos ayuda al consultar los registros del servidor.

Tenemos dos formas de progresar en este caso:

La primera es indagar constantemente en los distintos errores que resultan en problemas de detección de impactos. También hemos desarrollado herramientas para automatizar la detección y ayudar a los desarrolladores a evitar la introducción de nuevas. Se trata de un esfuerzo continuo por nuestra parte.

¡La segunda es trabajar contigo! Cuando los jugadores nos mandan vídeos de problemas de detección de impactos en acción, pueden ayudarnos a descubrir si hay algún error que debamos solucionar. A menudo vemos que los clips que nos envían tienen que ver con un problema de latencia en vez de con la detección de impactos, así que asegúrate de comprobar el indicador de rendimiento antes de comunicar un problema de registro de impactos. Sin embargo, como ya hemos dicho, hemos encontrado y resuelto errores de esta forma en el pasado, por lo que los informes pueden ayudarnos a mejorar el juego para todos. ¡Gracias por adelantado!

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

«Code:net» es un mensaje de error genérico que el juego muestra cuando ha se ha agotado el tiempo de espera del servidor. Puede deberse a una serie de problemas (nuestros o tuyos). De hecho, hemos descubierto que algunos de los errores de code:net más graves (y errores relacionados, como code:leaf, etc.) es posible que tengan que ver más con los servicios de Respawn que dan soporte al juego y que será necesario investigar.

Hemos adoptado una serie de medidas para reducir la probabilidad de que se produzca un error code:net. Asimismo, muchos jugadores consiguen resolver su situación tras ponerse en contacto con nuestro equipo de asistencia. Si no puedes iniciar sesión y recibes el mensaje code:net u otro similar, puedes comunicárnoslo mediante la página de la Ayuda de EA.

Dado que code:net es un mensaje genérico, puede referirse a distintos problemas. En las últimas semanas hemos conseguido abordar algunos de estos problemas, pero sabemos que aún nos queda mucho por hacer. Cuéntanos tus problemas e intentaremos solucionarlos lo antes posible. Créenos cuando decimos que este error nos fastidia tanto como a ti.

Y ahora lo más importante. Queremos abordar esta cuestión con transparencia. Muchos jugadores nos han preguntado por la frecuencia de actualización de nuestros servidores y por qué no la aumentamos de 20 Hz sin más, como han hecho otros shooters online. 

Hemos explicado cómo afecta la frecuencia de actualización de nuestros servidores a la tasa de actualización general de lo que ves en pantalla, por lo que esta pregunta es totalmente válida. Sin embargo, es más complicado de lo que parece comparar la frecuencia de actualización de los servidores de un juego con la de otro. Vamos a intentar explicar la razón. 

La frecuencia de actualización del servidor es el número de simulaciones que ejecuta el servidor por segundo. Se trata de un número fijo (consulta la sección de servidores a cámara lenta). Apex utiliza un modelo de réplica basado en instantáneas. Esto significa que al final de cada tick, el servidor guarda el estado del mundo y lo replica a todos los clientes. Esto incluye mucha información que permite que el diseño de armas, mapas y leyendas sea lo más fiel posible. 

Para tener éxito en Apex Legends, debes prestar atención a un montón de información que aparece por todo el mapa. Uso de habilidades tácticas, activación de pasivas, aparición de definitivas, llegada de packs de supervivencia o entrada de un nuevo pelotón al rango del dron de Crypto. No queremos que los jugadores se pierdan nada. Nuestros diseñadores pueden crear juguetes y herramientas que pueden ser de naturaleza global. Muchos juegos no calculan los estados del mundo completo en cada tick, por lo que es engañoso intentar comparar un juego con otro basándose en una sola cifra, como 20 Hz frente a 30 Hz. 

La pregunta es: ¿qué ocurre exactamente durante cada tick? Queremos que el estado del mundo sea lo más preciso posible. Por esta razón, nuestros servidores guardan todo el estado del mundo en cada tick. Si no lo hiciéramos, es probable que ahorráramos parte del coste de CPU en nuestros servidores, pero perderíamos precisión en nuestras simulaciones y no merece la pena. 

En pocas palabras, cuanta más alta sea la frecuencia de actualización del servidor, más alto será el ancho de banda que se enviará a todos los jugadores. Si pasáramos de un servidor de 20 Hz a un servidor de 60 Hz, se triplicaría el ancho de banda que utiliza el juego. A fecha de hoy, Apex Legends consume aproximadamente 60 kB/s al principio de una partida. Un servidor de 60 Hz consumiría 180 kB/s. Puede que no parezca mucho, pero es bastante y siempre buscamos formas de reducir el ancho de banda necesario. 

Pero, ¿qué importancia tendría que el ancho de banda fuera un poco más elevado? Mantener bajos los costes de ancho de banda para los juegos es mucho más importante que, por ejemplo, para la retransmisión de vídeos. Para aplicaciones de alto ancho de banda (retransmisión, descarga, etc.), la fluctuación o los enganches se pueden ocultar mediante el almacenamiento en búfer de minutos de una retransmisión, reducción de la calidad de la retransmisión, etc. Es probable que no veas fluctuaciones en la descarga y que no te importe que la velocidad sea variable en unos cuantos o incluso cientos de milisegundos. 

En los juegos no podemos permitirnos este lujo. Omitir un par de intervalos de 50 ms puede notarse y mucho. Si se omiten unos cuantos más, acabarás en la espiral mortal de tener que enviarte actualizaciones cada vez mayores para ponerte al día. Es imposible no recibir estas actualizaciones, porque el cliente necesita un estado perfecto del mundo para ser preciso.

El ejemplo anterior muestra lo complicado que es comparar la frecuencia de actualización del servidor de distintos juegos, porque la información que contiene cada tick varía. Otra complicación es que los límites de las entradas que los servidores pueden recibir y enviar no siempre son los mismos aunque tengan la misma frecuencia de actualización del servidor. En concreto: en muchos juegos, si un servidor funciona a 60 Hz, el cliente solo puede enviar entradas a 60 Hz. Si se ejecuta a 60 fps no pasa nada, pero si el cliente se ejecuta a 120 fps, perderás la mitad de las entradas. Esto no ocurre en Apex Legends, ya que procesamos correctamente la tasa de entradas variable. (como nota adicional, cuanto más alto sea el FPS en Apex, mayor será el uso del ancho de banda.)

Hemos comentado algunos posibles inconvenientes del aumento de la frecuencia de actualización del servidor. Pero ¿qué tiene de positivo pasar de, digamos, 20 Hz a 60 Hz? ¡Vamos, Respawn! ¿Eso no haría que los servidores fueran el triple de rápidos y mejores? ¡Hacedlo!

Basándonos en nuestros hallazgos, no sería una experiencia significativamente diferente. A continuación, explicamos por qué. 

Como hipótesis: supongamos que tienes una media aproximada de latencia o de ping de unos 50 ms. Recuerda que el ping mide la velocidad de un recorrido completo entre el equipo y el servidor. Así que, si no hay otros problemas como latencia fluctuante o retardo de hardware (por ejemplo, los dispositivos de visualización introducen un retardo de 20 a 50 ms), el servidor recibirá tu acción 25 ms (medio ping) después de pulsar un botón o mover el ratón. 

Dado que nuestros servidores funcionan a 20 Hz, actualizan el estado del mundo cada 50 ms (1000 ms cada segundo/20 ticks por segundo = 50 ms por tick). Así que, en el peor de los casos, el servidor procesará las entradas tras 75 ms (25 ms + 50 ms). 

Para descubrir lo que ese retardo de 75 ms significa en términos de experiencia, tenemos que pensar en la velocidad de fotogramas. Las matemáticas pueden ser complicadas, pero recuerda que en un juego a 60 fps, cada fotograma tarda unos 16,67 ms (1000 ms cada segundo/60 fotogramas por segundo = 16,67 ms por fotograma). Si el servidor procesa tus acciones tras 75 ms (como en nuestro ejemplo anterior) y tu juego funciona a 60 fps, el retardo entre tu entrada y su impacto en el juego es de 5 fotogramas (75 ms por actualización/16,67 ms por fotograma = unos 4,5 fotogramas, redondeando a 5 fotogramas, ya que no existe un medio fotograma). 

Si hacemos los mismos cálculos anteriores para un servidor de 60 Hz, obtendremos 41,67 ms de demora máxima entre la entrada y el procesamiento del servidor de esta (ping de 25 ms + [1000 ms/60 ticks por segundo = 16,67 ms por tick] = 41,67 ms). 

41,67 ms es definitivamente mejor que 75 ms, pero ¿qué resulta en la velocidad de fotogramas? Volvamos a suponer que ejecutamos a 60 fps. Cada fotograma tarda 16,67 ms, así que ahora el retardo entre las acciones y el servidor que las reconoce es de alrededor de 3 fotogramas (41,67 ms por actualización/16,67 ms por fotograma = unos 2,5 fotogramas, redondeando a 3 fotogramas, ya que no existe un medio fotograma). 

Si nos fijamos en estos cálculos, veremos que los servidores de 20 Hz resultan en alrededor de 5 fotogramas de demora y que los servidores de 60 Hz resultan en alrededor de 3 fotogramas de demora. Así, por el triple de bando de ancha y costes de CPU, se pueden ahorrar 2 fotogramas de latencia en el mejor de los casos. Tenemos algo positivo, pero tampoco es enorme y no solucionaría los problemas relacionados con un retardo normal (como que te disparen mientras estás a cubierto), los problemas a nivel de ISP o los errores (como los servidores a cámara lenta y el registro de impactos). 

Nuestro ejemplo ha examinado qué tiene de positivo pasar de 20 Hz a 60 Hz. Se pueden hacer los mismos cálculos para otros aumentos, como de 20 Hz a 30 Hz o incluso 40 Hz. Descubrirás que las ganancias en la velocidad de fotogramas también serían bastante pequeñas. Tendríamos que aumentar la frecuencia de actualización del servidor de forma drástica antes de poder empezar a notarlo. Incluso el salto de 20 Hz a 60 Hz sería como la diferencia entre 58 y 60 FPS. Esta diferencia no es insignificante, pero creemos firmemente que no basta con priorizar los cambios de la frecuencia de actualización del servidor respecto a otras mejoras más eficientes que podríamos aplicar.

Para finalizar, queremos reconocer la frustración total que causan los problemas online a los jugadores. Cuando sufres retardos, no se registran los impactos o los servidores funcionan a cámara lenta, no mola nada. Te saca del juego y puede resultar muy desmotivador cuando intentas trepar en las clasificatorias, realizar jugadas decisivas con los amigos o simplemente disfrutar de una velada tranquila. 

Parte de la complicación de hablar de problemas online reside en que cuando empezamos a explicar nuestros sistemas o nuestra postura sobre cuestiones como la compensación de retardo o la frecuencia de actualización del servidor, puede llegar a resultar frustrante para los jugadores que solo quieren que el juego sea mejor. Si tienes problemas de latencia, bloqueos del servidor, daños en la cuenta o cualquier otra dificultad al jugar a Apex Legends, es probable que no quieras saber lo que no estamos haciendo. 

En última instancia, solo queremos mejorar el juego. Cuanto mejor sea la experiencia online para ti, más gente jugará, lo que nos permitirá seguir realizando el trabajo que nos encanta. 

Por esta razón, en este blog hemos compartido una serie de mejoras que aplicaremos en un futuro próximo, entre las que se incluyen:

• Uso de alertas en tiempo real que nos permitirán identificar problemas y responder con mayor rapidez.
• Implementación de herramientas para identificar servidores y poder eliminar y sustituir rápidamente los servidores problemáticos.
• Nos centramos en los servidores a cámara lenta: eliminar servidores problemáticos es un paso, pero nuestro objetivo es que sea drásticamente menos común con cambios del código.
• Reducción de latencia con una mejor optimización de las nuevas funciones
• Solucionar errores de registro de impactos y crear herramientas de detección automáticas que nos ayuden a evitar la introducción de otras.

Pero queremos que sepas que esto no es lo único que hacemos. Estamos trabajando con socios, desde el nivel de servidor al nivel de ISP, para mejorar e invertir en nuestra infraestructura online. Nuestro objetivo es que los jugadores nos comuniquen menos errores y que la experiencia global sea mejor. Tenemos la intención de dar más detalles sobre estos esfuerzos en una futura publicación, cuando empecemos a ver que dan frutos. 

Creemos que si nos comunicamos más con nuestros jugadores sobre lo que nos concierne a todos, empezaremos a compartir un idioma común para hablar de las causas de los problemas a los que nos enfrentamos. Por eso hemos escrito esta publicación del blog. Esperamos que explique nuestro proceso de reflexión y desmitifique los tecnicismos de la gestión de un shooter online. También esperamos que este sea el comienzo de más conversaciones.

¡Gracias por leernos! 

- Samy (Ricklesauceur) y el equipo de Apex Legends

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

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

Regístrate hoy en nuestro boletín para recibir por correo electrónico las últimas noticias, actualizaciones, contenido entre bastidores, ofertas exclusivas de Apex Legends y mucho más (incluyendo otros productos, noticias, eventos y promociones de EA).

Esta programación puede experimentar cambios basados en las opiniones de la comunidad y en el desarrollo constante de nuestros contenidos y servicios en tiempo real. Nuestra intención es mantener siempre a la comunidad al tanto de todo, en la medida de lo posible. Más información en la página de actualizaciones del servicio online de EA:

https://www.ea.com/es-es/service-updates.

*Puede requerir una cuenta y suscripción a la plataforma correspondiente (se venden por separado). Para jugar es necesaria una conexión permanente a Internet y una Cuenta EA. Sujeto a restricciones de edad. Incluye compras en el juego.