¿Por qué algunos juegos en red usan interpolación y otros usan pathfinding para movimiento remoto?

Esta es una pregunta un poco abierta, pero me gustaría ver a alguien contribuir con un buen razonamiento para ambos.

Para un ejemplo rápido de ambos:

Modelo de interpolación

Piense en el modelo de Valve donde el cliente recibe actualizaciones de posición con frecuencia y los controles remotos actualizan sus posiciones utilizando la interpolación en estos datos.

Encontrar el camino

En este modelo, piense que el usuario envía un destino y todos lo encuentran.

¿Qué tipos de juegos son adecuados para cada uno y cuándo se debe usar cada uno?

He trabajado en el código de red para dos juegos en red AAA en tiempo real, uno para teléfonos inteligentes y otro para una consola portátil.

Para responder directamente a su pregunta "por qué", bueno, algunos juegos usan uno u otro porque les queda mejor que el otro. Esto depende no solo del tipo de juego, sino también del tipo de red de la que estamos hablando (los gabinetes de arcade vinculados tienen diferentes condiciones en comparación con los juegos que deben jugarse a través de 3G). Algunos juegos realmente usan ambos, o incluso completamente diferentes enfoques para sincronizar datos!

Me gustaría generalizar y considerar no solo los datos posicionales, sino prácticamente cualquier tipo de datos que pueda sincronizar entre dos clientes en red.

En lugar de dos posibilidades, me gustaría proponer un espectro entre actualizaciones duras y suaves.

• Las actualizaciones muy duras son eventos discretos que cambian inmediatamente el estado del otro cliente, sin ningún tipo de interpolación, ya sea porque los datos son de naturaleza crítica (un jugador murió), porque no es un tipo de datos para el que se aplica la interpolación (un en línea juego de ajedrez, mensajes de chat, etc.), o porque su red le permite hacer eso (piense en gabinetes de arcade vinculados donde el envío confiable de todo el estado del juego 60 veces por segundo está dentro del alcance de la posibilidad).

  Con este método, los retrasos en la red se mostrarán invariablemente como actualizaciones retrasadas y se manifestarán como caracteres saltando.

• Las actualizaciones duras con inter / extrapolación son similares a las actualizaciones muy duras, pero para el cambio constante de datos, para lo cual no es prácticamente posible enviar los datos de manera confiable cada vez que cambian. Piense en enviar una posición y un vector de velocidad; debería poder interpolar datos entre dos puntos y extrapolarlos después de ellos. Debe tener un plan de contingencia si los datos entrantes no están de acuerdo con sus extrapolaciones. Yo diría que la mayoría de los juegos que requieren actualizaciones de posición utilizan este método.

• Las actualizaciones de hardware con sincronización son similares a las de hardware con inter / extrapolación, pero solo requieren sincronización en raras ocasiones. Debe usar esto para datos que son realmente triviales para inter / extrapolar, como el reloj en un juego de lucha (una vez configurado en ambos lados, no es realmente necesario volver a sincronizar después)

• Las actualizaciones duras diferidas son similares a las actualizaciones duras, pero lo que está viendo son datos del pasado. Sospecho que en muchos juegos de arcade de música en Japón donde puedes tocar una canción contra alguien más, en realidad estás jugando contra datos de jugadores grabados en el pasado, posiblemente horas o incluso días antes. Por supuesto, este tipo de actualizaciones solo se pueden usar cuando realmente no interactúas con el otro jugador.

• Las actualizaciones suaves consisten en enviar datos de planificación y ejecutar el plan en todos los hosts. Esto es lo que llamas "pathfinding". La cantidad de datos necesarios para sincronizar datos como este es mucho menor; puede usar este tipo de actualizaciones cuando puede salirse con la suya con ciertas discrepancias en la forma en que se presentan los datos al usuario, como cuando se sincronizan cientos de enemigos.

  Las actualizaciones de datos de planificación en sí también pueden ser tan duras / suaves como desee, por supuesto.

• Se utilizan actualizaciones muy suaves cuando el resultado de una acción se puede calcular de manera confiable mucho antes de que suceda. Simplemente envía el resultado y el otro cliente simplemente lo reproduce. Por ejemplo, algunos juegos de navegador y teléfono inteligente le permiten luchar contra otras personas, pero la batalla real lleva horas resolver (piense en juegos similares a Travian). Es muy posible que estos juegos calculen el resultado en el momento en que se inicia la batalla, y solo se ven los resultados de esa batalla.

  Otro ejemplo de esto no conectado en red sería en Civilization 4 con animaciones de batalla habilitadas. Cuando atacas a alguien, el resultado de la batalla se calcula inmediatamente, pero puedes ver una animación de él reproduciéndose. Les puedo asegurar que la batalla no se calcula ya que se está animando.

Como puede ver, hay muchas formas de sincronizar datos, y estoy seguro de que puede imaginar muchas otras. Es probable que todos los juegos en línea, excepto los más simples, usen una combinación de estos métodos, dependiendo del tipo de datos que estén sincronizando, el tipo de juego e incluso el estado de la red (use actualizaciones duras cuando el retraso sea bajo y listo). para actualizaciones más suaves cuando el retraso aumenta).

No tengo ninguna idea sobre el proceso de desarrollo de Valve, por lo que esta es puramente mi opinión, pero:

Interpolación : Diría que sería mejor para juegos de ritmo rápido, como los FPS, por ejemplo, donde es importante tener una posición constante para un enemigo a tiempo entre jugadores. Interpolar significa que, incluso si se descartan algunos paquetes (AFAIK, la mayoría de los FPS multijugador usan UDP en lugar de TCP / IP, lo que no garantiza la integridad ni el orden en que llegan los paquetes), tendrá un movimiento suave en la pantalla.

búsqueda de ruta : si el tiempo no es un elemento crucial de su juego, y su algoritmo encuentra una ruta constante cuando se vuelve a ejecutar, la búsqueda de ruta podría ser interesante porque no requiere que envíe actualizaciones frecuentes y, por lo tanto, grandes actualizaciones con la posición de cada uno entidad. Diría que esto parece adecuado para un sistema basado en turnos, por ejemplo, en el que puede limitar la cantidad de solicitudes de red (una al comienzo del turno, una cuando finaliza el turno para asegurarse de que todos los clientes estén "sanos" " estado.

Una vez más, nunca he trabajado en un juego de red o en un gran estudio de juegos, pero por lo que he leído a veces así es como lo haría :)

La respuesta de Panda Pyjama es bastante buena.

Básicamente, la pregunta se reduce a cuál es la cantidad mínima de datos que puede enviar que pondrá a varios clientes en la misma conciencia del estado de los demás, y cómo maneja el retraso en el que durante ese retraso los clientes podrían estar en un estado diferente.

Por lo tanto, se genera de manera procesal, donde todas las interacciones se conocen de antemano es más fácil, ya que si se conocen todas las variables, entonces se conoce el resultado. Por ejemplo, aislar a alguien en una habitación, que conoce los métodos de procesamiento, y darle un conjunto de datos, puede predecir con precisión los resultados. Por lo tanto, puede dar los resultados a todos los demás clientes sin tener que esperar a que ese cliente termine su cálculo.

Sin embargo, no mencionó un método. Resultados forzados.

Si el sistema espera una acción de alguna entidad, y otras acciones dependen de esa acción, y otros cálculos tienen en cuenta esa acción, y ya se han procesado previamente con ese resultado esperado. Luego, para mantener la sincronización, todo el sistema se detiene mientras la única entidad que no está en el lugar correcto se vuelve a colocar correctamente en su camino.

Un ejemplo del mundo real son todas las demás entidades en un patrón de espera para asegurarse de que se me envíe la compensación adecuada.