¡Hola de nuevo! Somos el equipo de tecnología de la experiencia de juego de VALORANT y hemos venido a compartir con vosotros la segunda parte de los hallazgos de nuestra investigación y nuestros planes de cara a mejorar la coherencia del juego.

Si necesitáis repasar lo que escuchamos que nos llevó a iniciar este proceso, echad un vistazo a la publicación sobre el tema del mes pasado. En ella, explicamos a rasgos generales lo que nos han ido contando los jugadores y ofrecemos un resumen de las áreas de trabajo en las que estamos indagando (latencia, precisión y rendimiento de los jugadores con ping alto).

Como la publicación anterior ya explicaba el qué y el porqué de este proyecto, hoy queríamos ofreceros más detalles sobre una de las áreas principales en las que hemos implementado mejoras: la latencia y el búfer de red. Explicaremos la importancia de la latencia y el búfer en el contexto de VALORANT, daremos más información sobre nuestra investigación, plantearemos los arreglos y mejoras que hemos implementado y compartiremos los planes que tenemos pensado ejecutar a largo plazo.

Aquí os dejamos un pequeño resumen de lo que vendrá con el lanzamiento de la versión 4.10:

• Hemos encontrado y arreglado una serie de problemas que se daban tras los picos de inestabilidad de red, cuando se reducían los FPS del cliente, al usar Alt+Tab o tras largos periodos de retardo de red alto.
  • En estos casos, los jugadores afectados experimentaban una combinación de cierto retardo al procesar los comandos que enviaban al servidor y retardos en el movimiento de los jugadores enemigos en su pantalla.

• Con la versión 4.10, vamos a lanzar una serie de cambios que deberían mejorar el sistema de búfer de red en estas situaciones, y que permitirán a los jugadores consultar los datos que explican lo que está sucediendo entre bastidores.
• Estos ajustes lidian con la que, según nuestros hallazgos, es la causa más importante de esa sensación de latencia y tiempos de reacción incoherentes entre partidas, pero seguiremos monitorizando la situación muy de cerca e implementando más cambios en el futuro.
  • Si seguís teniendo problemas en vuestras partidas, esperamos que los nuevos gráficos os permitan cuantificar y medir las peculiaridades de vuestra experiencia.

• No dejéis de enviarnos informes con vídeos que muestren lo que veis (si es posible) a través del canal de asistencia al jugador.

LATENCIA Y BÚFER

En nuestra publicación anterior, mencionamos que seguimos estudiando la latencia y los resultados del sistema de búfer de red en VALORANT. Desde entonces, hemos zanjado esa investigación y nos hemos preparado para lanzar en la versión 4.10 correcciones para unos cuantos problemas que hemos identificado.

Antes de ponernos a profundizar, vamos a explicar un poco a qué nos referimos cuando hablamos de "búfer de red" y "retardos de procesamiento".

En los juegos en línea como VALORANT, vuestros comandos llegan al servidor para ejecutarse, porque la visión del juego que plantea el servidor es la que refleja la realidad. Cada vez que el servidor actualiza la simulación del juego (que es algo que sucede 128 veces por segundo), los comandos del cliente del juego tienen que ejecutarse para vuestro agente. Si vuestros comandos se retrasan en el viaje por la red, el servidor no espera a que lleguen, sino que simula un movimiento por vuestra parte.

En muchas ocasiones, la predicción del servidor no coincide con el comando que está en camino. Estas divergencias provocan correcciones de movimiento que, en el cliente, hacen que parezca que os teletransportáis a la ubicación correcta. Cuando hay demasiadas correcciones de este tipo, el juego va a tirones; mientras que, si el porcentaje es demasiado alto, resulta imposible jugar.

La mejor forma de evitar la predicción de movimiento por parte del servidor es tener activado el búfer de red y jugar con un breve retardo. Esta estrategia se usa con mucha frecuencia a la hora de transmitir datos por internet y ayuda a garantizar que el servidor puede reproducir los movimientos de vuestro agente en cada fotograma y sin interrupciones. No obstante, el búfer implementa un breve retardo antes de que el servidor pase a procesar vuestros movimientos y, cuando hay demasiado, puede parecer que estáis jugando con mucho más ping del que muestra el RTT de red (el tiempo de ida y vuelta de la red, por sus siglas en inglés).

Determinar y aplicar la cantidad correcta de búfer supone un cálculo de equilibrio muy importante. Si el búfer es muy leve, el servidor tendrá que predecir muchos movimientos, y el cliente, corregir muchas predicciones; si hay demasiado búfer, sube la latencia y seréis más susceptibles a problemas como la ventaja por asomarse en ángulos. Si damos en el clavo con el equilibrio, VALORANT os resultará fluido y responderá con agilidad.

Al igual que el servidor aplica un búfer a vuestros movimientos antes de reproducirlos, el cliente también tiene la necesidad de usar ese sistema para el movimiento de los enemigos antes de que se vea reflejado en vuestra pantalla. Esto sirve para que no parezca que los jugadores enemigos se teleportan por el mapa cuando tenéis mala conexión, y os proporciona una perspectiva estable y fácil de entender de los jugadores enemigos.

La investigación

Como parte de nuestra investigación, necesitábamos analizar mejor cómo estaban funcionando exactamente estos dos sistemas de búfer. Desarrollamos herramientas de debug nuevas para registrar cuánto tiempo tardaban los comandos en atravesar cada uno de los búfers. Con la ayuda de esas herramientas, empezamos a experimentar para ver si encontrábamos situaciones en las que los búfers de movimientos se comportaran de forma inesperada.

Una de las quejas de los jugadores que investigamos durante este proceso fue el aumento del tiempo de procesamiento de los disparos que se daba al utilizar Alt+Tab. Poner el juego en segundo plano con los FPS limitados crea un cuello de botella de FPS que genera problemas de rendimiento del cliente. Cuando el juego vuelve a primer plano, la subida de FPS puede provocar que la cola de movimiento del servidor se vuelva más grande de lo habitual. La sensación que genera esto en el cliente es como si estuvierais jugando con un ping muy alto que no se ve reflejado en los gráficos de RTT de red del juego.

Otra manera que encontramos de conseguir un efecto parecido era simular un pico de ping pronunciado en el cliente. Los picos de ping alto que se reducían bruscamente generaban una acumulación de comandos en la cola de movimiento del servidor de ese cliente. Por su parte, los picos de ping bajo que aumentaban generaban acumulaciones en las colas de movimiento del cliente de otros jugadores. En ambos casos, la acumulación de movimientos en la cola daba lugar a una latencia aparente mucho más alta que persistía hasta que la cola volvía a alcanzar el tamaño esperado.

Además, en ambos casos, el sistema actual acababa por resolver los problemas y adaptar los búfers al tamaño adecuado, pero descubrimos que, a veces, tardaba más de lo esperado en recuperarse del todo, lo que daba lugar a un proceso prolongado de latencia más alta a efectos prácticos.

Hemos implementado dos nuevas correcciones que deberían agilizar el proceso de vuelta a la normalidad de los búfers, así que solo deberíais ver los picos de latencia en márgenes de tiempo muy reducidos (cuando resulten esenciales para homogeneizar la experiencia de juego).

Correcciones y mejoras

La primera corrección que hemos implementado ajusta el tiempo que tardamos en reducir el tamaño de los búfers cuando algo requiere que aumenten puntualmente. Ahora, el sistema de procesamiento de movimiento se ajustará más radicalmente cuando el tamaño del búfer aumente.

Con este cambio, los comandos de búfer que hayan quedado almacenados se gestionarán más rápido que antes. Por ejemplo, antes del cambio, si había cinco comandos adicionales en el búfer, podía tardarse hasta cinco segundos en volver al tamaño de cola ideal. Con estas mejoras, el proceso se ejecuta en menos de un segundo. Eso quiere decir que los jugadores que experimenten problemas que afecten al juego, como parones o picos en la calidad de la conexión, se verán afectados por la latencia adicional del sistema de búfer durante un tiempo mucho más reducido.

Sin embargo, en los casos más extremos, la cola de movimientos con búfer puede ser tan larga que esperar a que el sistema de procesamiento de movimiento la gestione sigue requiriendo segundos, incluso a pesar del ajuste que mencionamos más arriba. Hemos decidido reiniciar el búfer directamente cuando esto suceda, lo que eliminará toda la cola de movimientos a excepción del comando más reciente. La ventaja de esto es que la latencia añadida desaparecerá de inmediato pero, a cambio, tendrá que implementarse una corrección de movimiento sí o sí.

Hemos descubierto que, en el caso de eventos de alto impacto (como altibajos pronunciados en los FPS o picos radicales de red), una corrección de movimiento es mejor para vosotros que esperar un par de segundos a que la cola de movimiento reajuste el tamaño del búfer. En la mayoría de casos, la corrección resultaba menos problemática que pasar un periodo más largo con la latencia más alta de lo normal, que es lo que sucedía antes de implementar la mejora. Un ejemplo de evento de alto impacto en el que es posible que se aplique esta corrección es cuando volvéis a poner el juego en primer plano después de haber usado Alt+Tab si tenéis un límite reducido de FPS establecido para cuando se minimiza el juego. Esto provoca un cambio pronunciado en los FPS que puede llevar a la situación problemática de búfer que explicamos, pero el nuevo cambio debería resolver estas situaciones rápidamente.

Un problema relacionado que nos hemos encontrado mientras investigábamos el sistema de búfer es que los jugadores que suelen tener un retardo de red alto van alternando entre colas de búfer largas y cortas, puesto que el sistema trata de ajustar la latencia con el número de movimientos que predice el servidor. Estamos trabajando en una solución que ajuste mejor el tamaño del búfer teniendo en cuenta los casos de retardo de red alto a largo plazo.

De cara al futuro

Además de los cambios expuestos más arriba, nos hemos dado cuenta de que no disponéis de una buena forma de visualizar los retardos de procesamiento de movimiento actuales. Los gráficos que diseñamos a nivel interno nos resultaron muy útiles para investigar este asunto, así que hemos decidido añadir uno nuevo a la interfaz del juego que se llama "Tiempo de ida y vuelta de red + retardos de procesamiento" y que refleja el tiempo que tardan los datos en hacer un viaje completo de ida y vuelta por vuestra red, además de los retardos de movimiento del servidor y del cliente.

El tiempo que se muestra en el gráfico debería ser equivalente al retardo que experimentabais al hacer el clásico "test del cuchillo". Si todo va sobre ruedas, un valor bastante razonable para esta métrica es de entre 20 y 30 ms más que el RTT de red (o tiempo de ida y vuelta), aunque el valor idóneo variará en función de vuestras condiciones de red y FPS concretas.

Además, hemos añadido un gráfico de retardo de tiempo de ida y vuelta de red que muestra los cambios en el RTT de red entre paquete y paquete. En muchas ocasiones, los picos de ping y las subidas de retardo de red necesitan más búfer de lo habitual, así que hemos decidido reflejarlo en un gráfico que podría ayudaros a diagnosticar problemas de red que, normalmente, no se mostrarían en el gráfico normal por los cálculos de media que se realizan para trazarlo.

También hemos implementado telemetría adicional con la que recopilar datos sobre los retardos de procesamiento que están experimentando los jugadores de una partida a otra. Iremos revisando esta información con frecuencia para asegurarnos de que el juego se mantiene en un estado saludable, para así determinar si las soluciones de más arriba están teniendo los efectos intencionados (y trabajar en soluciones adicionales si ese no fuera el caso).

Por último, a pesar de que leemos vuestras publicaciones en todas las redes sociales, queremos emplear nuestras encuestas de final de partida para obtener comentarios más detallados por parte de los jugadores, en los que nos expliquéis la calidad de vuestras partidas, de vuestra conexión y de la experiencia con las armas. Por ello, vamos a añadir unas cuantas preguntas y a revisar otras antiguas.

LA PRÓXIMA ACTUALIZACIÓN

Esperamos que estas mejoras a los sistemas de búfer ayuden a reducir las incoherencias que algunos de vosotros estabais sintiendo en partidas en las que vuestro ping parecía estable. Si veis que seguís teniendo problemas, confiamos en que los nuevos gráficos de información os ayuden a cuantificar esa sensación y a identificar las potenciales causas. Si tenéis problemas de coherencia y estáis grabando vuestras partidas, tener esos gráficos activados ofrece información adicional que puede resultar muy útil de cara a realizar un análisis más detallado.

Queremos concluir esta actualización dando las gracias de corazón a todos los que habéis publicado vídeos y análisis de problemas que habías visto o sentido en vuestras partidas. Valoramos mucho la pasión que sentís por el juego y lo mucho que os estáis esforzando para mejorarlo. Como siempre, nos tomamos vuestras opiniones muy en serio.

Estad atentos, porque pronto vendrá otra actualización en la que hablaremos sobre la selección de servidor y la relación que guarda con los resultados de los jugadores con ping alto.