Envío de diferencias de estado (deltas) y conexiones poco confiables

8

Estamos creando un juego multijugador en tiempo real, en el que cada jugador es responsable de informar su estado en cada iteración del bucle del juego.

Las actualizaciones de estado se transmiten utilizando UDP poco confiable .

Para minimizar el envío de datos de estado, hemos creado un sistema que enviará solo deltas (cualquier información de estado que se haya cambiado).

Sin embargo, este método es defectuoso, ya que un paquete perdido significará que otros jugadores no recibirán el delta, haciendo que el juego se comporte de una manera inesperada.

Por ejemplo:

Suponga que ese estado se compone de: {positionX, positionY, health}

Frame 1  - positionX changed --> send a packet with positionX only.
Frame 2 - health changed // lost !
Frame 3 - positionY changed --> send a packet with positionY only.

// Otros jugadores no saben sobre el cambio de salud.

¿Cómo se puede superar este problema entonces? enviar todos los datos no siempre es factible.

— spaceOwl
fuente

7

Aunque envíe datos utilizando UDP, deberá agregar su propia forma de confiabilidad para manejar situaciones como esta. UDP solo le brinda la flexibilidad de hacer lo que desea, en lugar de tratar con el formato confiable pero menos flexible de comunicación TCP. Los mensajes de confirmación o los paquetes de confirmación de un tipo deben usarse cuando sea necesario recibir información; de lo contrario, su cliente no tiene forma de saber si los datos que envió deben reenviarse. Por ejemplo, si envía información crítica y no ve una respuesta dentro de un período de tiempo establecido que confirma la recepción de esos datos, vuelva a enviarla.

— Evan
fuente

2

Gáname a eso. Sin embargo, debe tenerse en cuenta que no es necesario garantizar valores bastante volátiles, como la posición y otros datos físicos. Incluso en el caso de que esté mal en un cuadro determinado, de todos modos se solucionará el siguiente cuadro.

— jmegaffin

1

Buen punto, esto se ve con mayor frecuencia en los juegos cuando de repente un personaje se mueve a una nueva ubicación muy rápidamente (o se teletransporta allí todos juntos). La mayoría de los juegos lo manejan de diferentes maneras, pero el objetivo es el mismo. El servidor simplemente actualizó la posición de la entidad, y su cliente está actualizando inmediatamente o actualizándolo con un tiempo delta muy alto en unos pocos marcos.

— Evan

3

También puede solucionar el problema enviando una actualización de estado completa del servidor a los clientes, digamos cada segundo. Si un cliente no recibió un paquete, se comportará incorrectamente hasta que reciba la actualización de estado completa. Entonces estará sincronizado nuevamente.

— Matías
fuente

3

Muchos juegos usan UDP y TCP / IP para enviar / recibir datos y, según la frecuencia con la que se envían los datos, se utilizan diferentes protocolos.

Por ejemplo:

UDP: actualizaciones posicionales, y cualquier otra cosa que potencialmente podría enviarse / recibirse varias veces por segundo.

TCP / IP: acciones de inventario, acciones de hechizo / habilidad (la mayoría de las acciones realizadas por el usuario)

Realmente depende de la cantidad de tráfico de cada artículo. Si encuentra que está enviando actualizaciones de HP con bastante frecuencia, entonces tal vez tengan que estar en UDP.

— Subrayado, cero
fuente

1

El TCP generalmente no se usa para nada que requiera precisión en tiempo real debido a su capacidad de causar grandes picos de retraso.

— TheNickmaster21

Es bueno si quieres asegurarte de que tu paquete llegue allí. Cosas como las actualizaciones posicionales no son buenas para eso, pero si desea asegurarse de que su usuario presione un botón en un momento específico, TCP maneja todas las comprobaciones de errores y otras cosas que tendría que implementar para UDP para evitar la pérdida de paquetes.

— UnderscoreZero

Punto valido; Prefiero modificar UDP.

— TheNickmaster21

1

Si lee la revisión del código fuente de Quake 3 , explica el modelo de red que es muy similar a su diseño, pero con una solución para los paquetes descartados.

Esencialmente, en su modelo está enviando deltas contra el estado directamente anterior. En el modelo quake3, envía deltas contra el último estado acknolwedged del par.

— minismo
fuente