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.
- No necesita enviar ninguna información sobre algo que no ha cambiado.
- 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).
- 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.