PDA

Ver la Versión Completa : El retardo de comandos en For Honor



Ubi-Tali
17/04/2018, 15:55
https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/fh_inputlag_header_4_12_en_321582.jpg

Nota: usaremos 30 FPS como base en este artículo, ya que se trata de una configuración común en For Honor para las distintas plataformas.

ORÍGENES DEL AJUSTE TEMPORAL

The Art of Battle lleva siendo el elemento central del diseño de For Honor desde el principio. Para nosotros siempre ha sido vital que los ataques y bloqueos basados en la posición sean suficientemente claros y perceptibles. Aquí tenemos un ejemplo de un problema inicial con el que el equipo tuvo que lidiar durante el desarrollo del juego:


https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/video_1_lagcomp_rt_block003.mp4

En el vídeo 1 podemos ver un cambio de posición que bloquea el ataque cuando el jugador que se defiende introduce el comando en el último momento.


https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/video_2_lagcomp_rt_miss003.mp4

Comparemos esto con un bloqueo fallido, que ocurriría si el defensor cambia de postura 33 ms más tarde. Como se puede ver en el vídeo 2, pensamos que la diferencia no era lo bastante clara y que, por tanto, frustraría al jugador defensor. Decidimos que, para que la interpretación de los movimientos fuera más fácil, la diferencia entre un bloqueo con éxito y uno fallido debía ser siempre de al menos 100 ms.

https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/figure1_321586.gif

Para conseguirlo, creamos el sistema de "ajuste temporal", que alineaba las acciones de los jugadores cada 100 ms del reloj mundial. Como puede verse en la primera imagen, aunque el jugador 1 haya pulsado el botón de ataque 33 ms antes que el jugador 2, ambos se activan a la vez, lo cual ocasiona un doble impacto.

PROBLEMAS DEL AJUSTE TEMPORAL

La principal desventaja del ajuste temporal es que implementaba un retardo aleatorio adicional de 0 ms, 33 ms o 66 ms en función del momento en que el jugador ejecutaba el comando respecto al reloj mundial. Por aquel entonces, cuando todavía estábamos en fase de desarrollo, el equipo creía que era un margen aceptable, pero pronto cambiamos de parecer.

Mientras seguíamos trabajando en el equilibrio y la comodidad del sistema, recibimos comentarios de insatisfacción de evaluadores internos y externos sobre el tiempo de reacción al introducir comandos durante el cambio de posición. Decidimos quitar el ajuste temporal en el cambio de posición, lo cual resolvió algunos problemas de reacción al introducir los comandos, pero también socavó gran parte del propósito del ajuste temporal.

Tras el lanzamiento del juego, decidimos quitar del todo el ajuste temporal, ya que estábamos empeñados en mejorar la fiabilidad de la introducción de comandos. Pero como este sistema era también una forma de compensar la latencia del servidor, eliminarlo tendría otras consecuencias para el juego.

Vamos a echar un vistazo a distintos ejemplos que explican cómo funcionaba este sistema cuando estaba activo. Para simplificar las cosas, asumiremos que tenemos 100 ms de latencia del servidor del atacante al defensor.

https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/figure2_321587.gif

En la segunda imagen, el atacante introduce el comando a los 400 ms, por lo que el ataque empieza en el acto. El defensor lo percibe 100 ms más tarde, por lo que se pierde los primeros 100 ms del ataque.

https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/figure3_321588.gif

En la tercera imagen, el atacante introduce el comando a los 366 ms, por lo que el ataque empieza a los 400 ms. Estos 33 ms de retardo funcionan como compensación de la latencia del servidor, ya que el defensor solo se pierde los primeros 66 ms del ataque.

https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/figure4_321589.gif

Por último, en la cuarta imagen, el atacante introduce el comando a los 333 ms, así que el ataque empieza a los 400 ms. Aquí tenemos 66 ms de retardo que hacen que el defensor solo se pierda los primeros 33 ms del ataque.

Pero como esta compensación de latencia del servidor era aleatoria y poco fiable, no resultaba ideal para representar la habilidad de los jugadores para reaccionar a los ataques. Pensamos que, como una de cada tres veces los ataques no tenían compensación de latencia, quitar el ajuste temporal no impactaría de forma negativa en la reacción de los jugadores. Sin embargo, los comentarios de la comunidad dejaron bien claro que debíamos encontrar un reemplazo adecuado para el inconsistente sistema de ajuste temporal, algo que permitiera compensar todo lo que se perdía al eliminarlo.

MEDIDAS ACTUALES

https://ubistatic19-a.akamaihd.net/resource/es-es/game/forhonor/fh-game/figure5_321590.gif

Nuestra propuesta de solución es un enfoque híbrido del retardo de comandos: todos los comandos que se consideren "ofensivos" (la lista está más abajo) se retrasarán siempre 33 ms. Este valor no afecta mucho a la reacción a los comandos, ya que solo influye en las acciones "ofensivas", que son, por defecto, largas. Como puede verse en la quinta imagen, si un jugador realiza un ataque estando en reposo, dicho ataque comenzará 33 ms más tarde en lugar de hacerlo al instante. De esta forma, la parte del ataque oculta al defensor se reducirá con el retardo de comandos (de 100 ms a 66 ms), por lo que tendrá más tiempo para reaccionar.

¿Qué se considera un comando ofensivo?


Los ataques ligeros siempre se consideran comandos ofensivos.
Los ataques pesados se consideran ofensivos salvo cuando son paradas, que no sufrirán retardo.
La rotura de guardia se considera ofensiva salvo cuando se usa defensivamente para contraatacar con una rotura de guardia. En esos casos no sufrirá retardo.
Si el cambio de posición tiene lugar al mismo tiempo que un ataque ligero o pesado, dicho cambio de posición se retrasará hasta el inicio del ataque.
Las esquivas, cancelaciones o fintas se consideran ofensivas si se activan durante el retraso de un comando ofensivo para evitar una inversión de comandos que causaría parpadeos.
Ejecutar roturas de guardia, ataques ligeros o ataques pesados se considera una acción ofensiva, ya que pueden activar ataques de algunos personajes (como la Tormenta rauda del Orochi).

SIGUIENTES PASOS

Tras haber realizado pruebas internas con miembros de nuestra comunidad, creemos que este es un primer paso en nuestro objetivo de mejorar las reacciones y los combates en general. Tendrá un ligero impacto en los tiempos de ciertas acciones como las cadenas, enlaces o cancelaciones, ya que los comandos deberán ejecutarse 33 ms antes. Estamos investigando otras formas de mejorar la gestión de la latencia en el juego, pero queríamos introducir ya este primer cambio para que los jugadores disfruten de una mejor experiencia lo antes posible. Como siempre, seguiremos informando de todas las actualizaciones sobre este tema.