¿Los buenos juegos multijugador/mmo cliente<>servidor utilizan latencia en los cálculos de movimiento?

Question

Hay un par de preguntas aquí.

Imagine que tengo el cliente A que va a enviar el siguiente mensaje al Servidor:"INICIAR EL MOVIMIENTO HACIA ADELANTE".

El servidor no recibirá este mensaje al instante, ya que hay un retraso debido a la latencia.

Pregunta 1:ping (o mejor: Tiempo de viaje) es la cantidad de tiempo que le toma al cliente enviar un mensaje al servidor y recibir una respuesta.¿Significa esto lo siguiente si puede ignorar el tiempo que le toma al servidor darse cuenta de que recibió un mensaje y comenzar a enviar una respuesta (esto debería ser muy corto)?

1. tiempo que le toma al cliente enviar algo al servidor = tiempo de ida y vuelta / 2
2. tiempo que tarda el servidor en enviar algo al cliente = tiempo de ida y vuelta / 2

Entonces, cuando el cliente A envía ese mensaje, el servidor supuestamente recibirá ese mensaje en un tiempo de ida y vuelta / 2 milisegundos después de que el cliente haya enviado el mensaje.Esto me lleva a la siguiente pregunta.

Pregunta 2:¿El cliente debe enviar primero el paquete y luego esperar un tiempo de ida y vuelta/2 milisegundos antes de ejecutar ese comando en el lado del cliente (en este caso:avanzar) para compensar con la latencia/retraso?

Ahora, el servidor enviará el siguiente mensaje a todos los jugadores cercanos:"EL CLIENTE A AHORA AVANZA".Luego, estos clientes se asegurarán de que el personaje del cliente a comience a moverse, esto me lleva a la siguiente pregunta.

Pregunta 3:¿El cliente que recibe el mensaje de que otro cliente se ha movido debe tener en cuenta que este mensaje fue enviado por el servidor en un tiempo de ida y vuelta / hace 2 milisegundos?¿De modo que el tiempo actual utilizado para las marcas de tiempo de los cálculos de movimiento debería reducirse en el tiempo de ida y vuelta / 2?

En mi opinión, todos estos métodos garantizarían que la sincronización mejore entre los clientes, ya que se tiene en cuenta la latencia.¿Es esta la forma correcta de hacer las cosas?¿La mayoría de los buenos juegos multijugador hacen esto?¿Algún comentario, sugerencia, alternativa o grito aleatorio pero relacionado que te gustaría dar?Gracias de antemano.

Answer 1

Creo que en la mayoría de MMO que su cliente se mueve en general sin interacción con el servidor a menos que se produce mala lag. El servidor reproduce el movimiento con la ayuda de los mensajes que el cliente envía al servidor. Así que si, por ejemplo, el servidor se queda, el cliente dejará de recibir retroalimentación desde el servidor y volver a la posición de que el servidor determine que es mayor. Es por eso que saltar hacia atrás varias tramas durante el mal lag. De esta manera el servidor también tendrá control sobre su velocidad, de manera que no se speedhacking. Si el cliente se mueve a una velocidad determinada, que es más de la velocidad determinada por el servidor, sólo tendría que saltar de nuevo los fotogramas adicionales.

Otros clientes no dejaban que se mueve en absoluto sin respuesta del servidor dentro de una cierta cantidad de tiempo. Este es el tiempo que iba a experimentar 'freeze-lag'.

Por supuesto, también hay ocurrencias donde el servidor simplemente tomar la posición enviada por el cliente y que confía ciegamente. Estos son los juegos que son generalmente vulnerables a teletransportarse hacks.

Cuando se trata de la posición de otros jugadores efectivamente existe un retraso, que se puede ver si se toma dos ordenadores, se conectan a un juego como el wow y mover los dos personajes simultaneamente. Se podría ver que en ambos equipos el carácter no local comenzará a moverse después de que realmente comenzó a moverse.

El cliente por lo general tienen algún tipo de compensación de lag. Así que si otro jugador se mueve en una dirección determinada y luego se detiene, el cliente seguirá simular el movimiento de ese jugador hasta que se reciba un mensaje del servidor que cambió de dirección o parado de moverse. Es por ello que otros jugadores pueden saltar hacia atrás y adelante cuando el ping es alto. Esta es también la razón por los jugadores pueden parecer sólo deslice / carrera / caminata de distancia cuando se pulse lagspikes y luego volver a su posición real cuando sus clientes recibiera derechos posiciones desde el servidor.

Por supuesto, esto cambia de un motor a otro, pero es un abordaje más bien general.

Edit: Se me olvidó añadir que es muy común que el servidor utilice también la compensación de retraso. Si se golpea a alguien en un MMO que está dentro del alcance de ustedes, esa persona podría no estar en el rango de los servidores de vista. Por lo que el servidor toma la latencia tanto para sus clientes y trata de hacer coincidir si estuviera realmente en el rango de entre si o no.

Answer 2

Esta es una vieja pregunta, pero he trabajado a cabo recientemente un código similar así que quizás esto ayude a alguien.

Si la latencia es siempre útil en el cálculo. Pero es un poco más compleja que la RTT. el tiempo de ida y vuelta está siempre cambiando ... el código de red puede mantener un promedio, pero la varianza a partir de ese promedio es grande.

El cliente local, cliente remoto y el servidor de todos predicen la posición actual usando algoritmos. Los siguientes datos se encuentra cerca de típico:

• Tiempo: t
• Colocación: Posición (x, y, z) y orientación (x, y, z, w)
• Movimiento: Linear vector movimiento dar dirección con una longitud como la velocidad (x, y, z), y rotacional vector movimiento dando eje con la longitud como la velocidad de rotación (x, y, z)

Es necesario que extrapolan los algoritmos de un [L, P, M] ajustado a la simtime. Yo no proporcionará los que están aquí.

Cuando el cliente se registra un cambio en la unidad del buque en [E, P, M], que no vas a encontrar en el servidor hasta T + delta T. Pero si delta T está dentro de la tolerancia de las latencias de red comunes, el servidor puede decir "sí sucedió en T, acepto eso." De lo contrario, podría querer corregir el cliente diciendo "No eso es fuera de tolerancia, sucedió en mi tiempo T'", en cuyo caso el cliente tendrá que reproducir todos los posteriormente conducidos [T, P, M] cambios de un corregida del servidor (lo que significa que necesita para mantener una cola o lista de ellos).

El siguiente cliente obtendrá en T + delta T + differentdeltaT. No es posible que cambiar lo que ya ha simulado, así que si no está retrasando es la simulación saltará la nave a distancia y verá un marco tirón. Es por eso que los barcos accionados a distancia deben tener sus simulaciones retrasado por un tiempo consistentemente mayor que 2 * typicaldeltaT. Debe ser un retardo constante, o un retraso que cambia gradualmente, y en tiempos de retardo severo verá marcos tirón, sin embargo

Puede suavizar todos los tirones con código suavizado extra, pero no lo hace hasta que su código es otra manera impecable, ya que sólo hará que sea imposible ver dónde están los problemas.

Debe tener una buena referencia de tiempo sincronizado. Una gran cantidad de código por ahí lo hace más bien descuidadamente (por ejemplo RakNet no lo hace (o no) lo hacen muy bien). He aquí una buena pista: en el corto plazo se puede presumir que los relojes de todo el mundo están funcionando a la misma velocidad, y sólo tendrá que averiguar lo que el desplazamiento es, a fin de mantener una ventana de máxima y mínima desviación y cerrarla a medida que aprende; En el largo plazo que necesita para compensar los clientes cuyos relojes se están ejecutando rápido o lento, por lo que permitir que la ventana se abra si se sabe con seguridad que debe. Debe utilizar un timesource local que está aumentando de forma monótona y no tecleó fuera de la velocidad del procesador (que hoy en día es variable).

No, no se demore la simulación local cuando los locales "Avatar" se mueve. Parecería demasiado insensible. Se podría retrasar ligeramente (hasta tal vez 50 ms) para ayudar a mejorar la sincronización, pero un retraso todo el camino a la RTT haría que su juego parece frustrante que no responde. Definir una opción para retardo local y jugar con él, porque un pequeño retraso constante puede ser aceptable y mejorar la sincronización. Pero no es necesario y puede causar muchos problemas, así que recomiendo hacer que el código anterior. (Si usted está tratando de hacer un juego FPS cuerpo a cuerpo, que necesita para hacer esto y todos los demás ayuda que puede obtener).

En cuanto a la prevención de trucos frente a la suavidad de simulación: En primer lugar, los clientes no sólo debe extrapolar a partir de la última posición, cuando cambia la posición oficial. Se debe registrar un vector de ajuste y mover lentamente de la ruta antigua a la nueva ruta para la suavidad (pero como he dicho anteriormente hago esto último código o se enmascarar otros insectos). En segundo lugar, el servidor debe tolerar una amplia gama de retrasos ... incluso en máquinas en la misma Ethernet del retardo de paquetes normalmente se ejecuta de 5 ms a 100 ms o menos ... Ese es un rango. Por supuesto que necesita para cortarapagado y decir "si usted dice que movió en el tiempo T pero tengo el paquete en T + some_large_number entonces creo que está tratando de ajustar el pasado y mintiendo." some_large_number no debería ser mucho más grande que el promedio de RTT para mantener a la gente honesta.

Las simulaciones nunca serán bien sincronizados. Ellos deben permanecer dentro de 400 ms o menos a través de Internet, pero sin duda serán desviarse fuera de eso durante los tiempos de retraso ... a 30 segundos o más, y hay que tolerar las cosas que las que debido a que no son raros. Dado que Internet está limitado por la velocidad de la luz en el cobre, siempre se puede esperar de un solo sentido latencias para estar normalmente en el intervalo de al menos 100 ms mínimo para la medida de sus clientes, a menudo 500 ms o más.

Por lo tanto le recomiendo que no trate de hacer un juego FPS cuerpo a cuerpo a través de Internet (algunas empresas grandes probar, pero siempre tendrá problemas). Hay trucos que puede hacer si está utilizando proyectiles (mediante su ejecución en una simulación rápida y lenta en el otro), de modo que, aunque el tiempo está apagado, se ve en. Además, los juegos de FPS utilizan la regla que se basa en la simulación de detección de atacantes golpeó ... se siente más mal cuando el atacante sabe que estaba muerto en el blanco y pierde, entonces cuando un defensor sabe que estaba fuera del camino y es golpeado de todos modos. Tienes que elegir uno u otro, y psicológicamente eso es lo que se ha hecho. Cuerpo a cuerpo requiere un nivel de sincronización que es francamente imposible y la mayoría de las compañías de juegos no tocará MMORPG FPS cuerpo a cuerpo, sino más bien utilizar la función Auto-selección de objetivo (intentar jugar Mortal Online, verá lo que quiero decir).

Buena suerte.

Answer 3

para el Q1:. Que se ve bien para mí

P2: La forma en que he hecho esto en el pasado es: si quieres que las cosas se sienten sensibles, comenzar a ejecutar la acción al instante en la simulación del cliente, el servidor simula adelante en juego en tiempo cuando la persona que inició la acción . es decir, el cliente sabe en qué ms en el tiempo de juego-simualation que comenzó, por lo que el servidor puede comenzar en ese momento también (nota: esto es siempre hacia atrás en el tiempo a partir de garrapatas actual del servidor, así que hay que guardar el estado atrás en el tiempo para hacer esto).

P3: los clientes realmente sólo necesitan saber que están simulando en el momento X, y el servidor dice que el conjunto de eventos {A, B, C} {ocurrió en momentos X, Y, Z}. A continuación, el cliente y el servidor pueden simular adelante con la misma información y en general mantener la sincronización (excepto cuando se producen conflictos simultáneos). En esos casos, usted tiene las cosas servidor de re-sincronización para que por lo general termina dentro de un margen bastante estrecho de error y sobre todo una experiencia sin problemas.

Si su objetivo es mejorar la percepción de latencia también puede ser que sólo tratar de confiar en el cliente.

Answer 4

Hay varios modelos de red para resolver estos problemas;

En juego de red, es necesario sincronizar dos cosas, una es el tiempo, otro es el espacio.

1. Un modelo de juego de red llamado unísono;

usted debe tener una mirada en el artículo escrito por edad de estudio de juegos empire2, que describen los detalles en el modelo mismo paso.

En este marco lógica modelo, el cliente y el servidor de juego de correr por el marco, por ejemplo, RTS utilizan 100 ms como un marco, servidor y el cliente se sincronizarán Id marco, lo que significa para sincronizar el tiempo.

Cliente al bastidor 50, Comando Enviar MoveForward, pero no ejecutarlo inmediatamente, el cliente le dirá servidor para ejecutar comando de movimiento en el bastidor 51; Luego, cuando llega marco 51, servidor y el cliente se ejecute el comando al mismo tiempo. por lo que el cliente y el servidor de la lógica serán iguales.

En dicho modelo, en el cuadro 50, el cliente y el servidor se ejecutará comando emitido en el marco de 49 tal vez, por lo que hay todos los días 100 ms o más retraso en la retroalimentación de entrada del cliente.

el desfase entre el cliente y el servidor no sólo contiene la red RTT, pero también contiene retardo de trama lógica, que es 100 ms;

En este modelo, para sincronizar el espacio, lo que necesita para hacer su código de cliente y servidor de código determinista, por lo que sólo se puede sincronizar el mando y frameId, no hay necesidad de sincronizar estado de entidad.

En este modelo, la retroalimentación de entrada es grande, por lo que necesita para ver la animación o el sonido para ayudar jugador ignorar el retraso.

2. otros modelos utilizan sincronización estado

en este modelo, también es necesario sincronizar el tiempo, por lo que el cliente va a adivinar qué hora actual en el servidor.

cuando la entrada de jugador, cliente a moverse de inmediato, a continuación, enviar comandos de movimiento o posición de destino el cliente al servidor, fecha y hora actual del servidor, que se estima por el cliente.

cuando el servidor recibe el comando de cliente, se sabe cuando se emite el mandato en el tiempo del servidor en el cliente, que tratará de ejecutar el comando con la extrapolación.

todos los demás clientes recibirán la orden, con su tiempo de servidor, los clientes de todos los otros van a tratar de extrapolar el comando.

Estas tecnologías incluyen la predicción de clientes, compensación de lag Server, servidor de entidad de interpolación.

En este modelo, la retroalimentación de entrada del cliente es corto, pero para algunos órdenes de impulsos, como el uso de habilidades, todavía tenemos que utilizar el método unísono, con efectos de animación, sonido y partículas para el maquillaje del tiempo de realimentación de entrada.

En juego de red, hay al menos dos tipos de comandos, primero como el movimiento, el comando se ejecutará durante un cierto tiempo, como un flujo constante, que tiene el atributo de continuidad.

Por otro como el uso de la habilidad con el tiempo frío, se llevará a efecto de comandos en un impulso, debemos tratarlos de forma diferente.

Answer 5

Algunos buenos juegos multijugador utilizan un mecanismo que permite a los jugadores moverse sin problemas incluso en tiempos de ida y vuelta intensos, permitiendo al cliente decidir y enviar la posición del jugador al servidor.Existen mecanismos de verificación de fraude, pero el cliente es libre de hacerlo.Entonces, si el tiempo del viaje de ida y vuelta se vuelve loco, verás personas saltando de un lugar a otro mientras te mueves sin problemas.Incluso algunos juegos MMO lo llevan al siguiente nivel al permitir que el cliente maneje contenido para un solo jugador sin el consentimiento del servidor.Sólo se envían al servidor estadísticas, informes de batalla y alguna otra información junto con algunos datos de verificación de fraude.