¿Qué datos intercambiar en juegos multijugador en tiempo real?

Soy un programador aficionado y ahora tengo curiosidad por saber qué datos se intercambian en una sesión de varios jugadores en juegos en tiempo real como Starcraft 2. Hice un montón de búsquedas. Encontré que gafferongames.com ofrece una muy buena visión general de los temas a considerar.

Glenn en su artículo y comentarios da un caso muy fuerte para usar UDP sobre TCP, pero SC2 obviamente usa TCP. Para qoute Gleen,

El problema con el uso de TCP para juegos es que, a diferencia de los navegadores web, el correo electrónico o la mayoría de las otras aplicaciones, los juegos multijugador tienen un requisito en tiempo real para la entrega de paquetes. Para muchas partes de su juego, por ejemplo, la entrada del jugador y las posiciones de los personajes, realmente no importa lo que sucedió hace un segundo, solo le importan los datos más recientes.

Entonces, a partir de su declaración, supongo que su enfoque es enviar el estado completo del juego de cada unidad en cada cuadro. Si el servidor no recibe una entrada del jugador en el marco actual, entonces solo es suerte para ese jugador. Para God of War: Acension, en el que es el desarrollador principal de la red, creo que esto debería funcionar bastante bien.

Para SC2, debido a su capacidad de repetición, mi intuición me dice que el motor subyacente es una "máquina de reproducción de entrada de usuario" de paso fijo determinista, donde los únicos datos intercambiados son las entradas del jugador . De ahí que la declaración de Glenn sea completamente irrelevante para SC2. La entrada del jugador es importante, y la secuencia de entrada es aún más importante. No creo que sea factible que SC2 envíe un estado de juego de 200 unidades y más a 30-60 FPS.

Pregunta: Podría estar equivocado, pero he intentado identificar 2 posibles tipos de datos. ¿Cuáles son otras técnicas? Será bueno qoute el juego si quieres.

EDITAR: encontró este enlace sobre el modelo de red de Starcraft

Glenn en su artículo y comentarios da un caso muy fuerte para usar UDP sobre TCP, pero SC2 obviamente usa TCP.

Glenn habla principalmente de juegos basados ​​en la física, es decir. juegos de disparos en primera persona y juegos de conducción. Estos tienen diferentes requisitos para los juegos de estrategia en tiempo real donde las posiciones precisas de las unidades en cada paso lógico son importantes. Entonces las estrategias de comunicación son necesariamente diferentes.

"Tiempo real" significa cosas diferentes en diferentes contextos. Los juegos no son "difíciles" en tiempo real, ya que si un mensaje llega tarde, todo se rompe. (Al menos, no hay una buena razón para que un juego sea tan exigente, ya que un sistema solo de software debería poder recuperarse de los retrasos en el procesamiento, a diferencia de una estación de energía nuclear o un equipo médico, por ejemplo). Los juegos son realmente 'suave' o 'firme' en tiempo real. ( Definiciones en Wikipedia como de costumbre .) El tipo de juego hace una diferencia en cuanto a qué tan rápido necesita la información, si puede perder información y salirse con la suya, etc. Baste decir que TCP es lo suficientemente bueno para muchos juegos, pero para otros juegos, UDP es preferible.

Supongo que su enfoque es enviar el estado completo del juego de cada unidad en cada cuadro.

Enviaría suficiente información para reconstruir el estado relevante del juego de cualquier unidad que haya cambiado.

1. No necesita enviar ninguna información sobre algo que no ha cambiado.
2. No necesita enviar el estado completo si puede enviar suficiente información para que el destinatario construya el nuevo estado a partir del estado anterior. (por ejemplo, simplemente envíe un valor delta relativo a un estado anterior. O simplemente envíe las partes del estado que han cambiado y no el resto).
3. Si dos juegos ejecutan exactamente el mismo algoritmo y tienen exactamente los mismos datos, simplemente puede enviar entradas y el destinatario resimula los efectos localmente para derivar el nuevo estado.

La mayoría de los juegos no cumplen los criterios para 3, por lo que usan 1 y 2 en su lugar. Sin embargo, muchos juegos de estrategia en tiempo real pueden hacer uso de 3.

Además, no necesariamente tiene que ser "cada cuadro". El concepto de marco también es nebuloso. ¿Es un marco de renderizado? ¿Es un lote de lógica? ¿Es un marco de datos de red que se envía? ¿Los tres siempre se alinean uno a uno o se obtiene una velocidad de gráficos variable con velocidades lógicas fijas? Algunos juegos, especialmente los juegos de estrategia en tiempo real como Starcraft 2, o juegos con capacidad de repetición (a medida que toca) les gusta mantener todo en perfecto estado al tener actualizaciones regulares de la red (que pueden o no coincidir con 'marcos' en otros sentidos) pero Este no es un requisito para todos los juegos. Muchos juegos solo envían actualizaciones de forma semi-regular, dependiendo de qué tan atrasados ​​estén dispuestos a dejar que los clientes corran.

La entrada del jugador es importante, y la secuencia de entrada es aún más importante. No creo que sea factible que SC2 envíe un estado de juego de 200 unidades y más a 30-60 FPS.

Muchos juegos no necesariamente tratarán un marco de renderizado como un marco lógico. Pueden tener 60 FPS en gráficos, pero solo tienen 10 actualizaciones lógicas por segundo y envían 1 actualización de red para cada una. Pero incluso 30 actualizaciones de red por segundo son razonables si utiliza el método 'enviar entrada', sin duda.

Intenté identificar 2 posibles tipos de datos. ¿Cuáles son otras técnicas? Será bueno qoute el juego si quieres.

No es tanto que existan técnicas distintas, sino varias restricciones diferentes en los sistemas, y la importancia de cada restricción variará de un juego a otro. Entonces solo tiene que elegir un sistema que funcione para usted.

• Pocas unidades, que se mueven de forma rápida y errática a través de la entrada del usuario, la latencia es sensible, la sincronización exacta entre sistemas no es importante: difunde las posiciones a través de un protocolo poco confiable (por ejemplo, UDP) para obtener la máxima velocidad, y los mensajes perdidos no importan como uno nuevo ven pronto. Simule la física localmente para mejorar la calidad del renderizado, pero corrija las posiciones cuando llegue nueva información. Bueno para tiradores y juegos de conducción.
• Muchas unidades, pero la mayoría son irrelevantes, y se mueven lentamente: solo envían actualizaciones para unidades cercanas al destinatario, las envían como cambios en lugar de estados completos, las envían con poca frecuencia y envían un protocolo confiable (por ejemplo, TCP) para evitar tener preocuparse sobre cómo manejar las actualizaciones perdidas. Bueno para los MMO.
• Muchas unidades, movidas por la IA en función de la entrada previa del usuario, la sincronización exacta entre sistemas es muy importante: envíe la entrada del usuario con marca de tiempo sobre un protocolo confiable y resimule localmente para que los algoritmos del juego mantengan el estado sincronizado. Bueno para RTSes y juegos por turnos.

La técnica principal que debe conocer es la técnica de "1500 arqueros". Era famoso por Age of Empires, pero también se usa en otros juegos como OpenTTD (de código abierto) (basado en Transport Tycoon Deluxe).

Para ser claros: con esta técnica, no es necesario que envíe NINGÚN estado del juego mientras juega. Todo el estado del juego se envía al inicio inicial, se conecta y se vuelve a sincronizar. Lo único que necesita enviar regularmente son señales de tiempo y verificaciones de sincronización. Normalmente, los comandos de jugador se envían normalmente desde el cliente al servidor y viceversa. Si un jugador no ejecuta comandos (como es el caso en la mayoría de los ticks), no es necesario enviar datos.

Ver este enlace.

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

Actualización: Kylotan llama a esta "técnica 3" en la respuesta.