¿Cómo se ven los protocolos de los juegos de estrategia en tiempo real como Starcraft y Age of Empires?

Puedo entrar en muchos detalles sobre esto, pero primero, lee "1500 arqueros" http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php y esto responderá a muchas de sus preguntas. Aquí hay un resumen: En primer lugar, la mayoría de los juegos utilizan UDP debido a la naturaleza en tiempo real del juego. El bucle de juego se ve algo como esto:

1. leer datos de red
2. hacer predicciones del lado del cliente y comparar con donde dice la red sus objetos deben realmente be
3. meterse con la física para fudge lo que la red dice con lo que su el estado local del juego es
4. enviar datos de vuelta a la red en función de lo que hizo esto frame (en todo caso)
5. render

Eso es enormemente simplificado y "meterse con la física" podría ser fácilmente un libro de 200 páginas por sí solo, pero implica predecir en el lado del cliente dónde es probable que esté algo, obtener datos del servidor que es antiguo pero que indica exactamente dónde estaba/debería estar un objeto, y luego interpolando esos valores de alguna manera para hacer que el objeto parezca "lo suficientemente cerca" de donde realmente se supone que debe estar que nadie se da cuenta. Esto es súper crítico en los shooters en primera persona, pero no tanto para la estrategia en tiempo real.

Para la estrategia en tiempo real, lo que normalmente sucede es un sistema basado en turnos donde el tiempo se divide en trozos discretos llamados "turnos" que ocurren secuencialmente y cada turno tiene un número generado por una función monótona que garantiza valores cada vez mayores en un pedido particular sin duplicados. En cualquier turno n, cada cliente envía un mensaje a todos los demás clientes con su acción prevista en el turno n + m, donde m es un número arbitrario que generalmente es bastante pequeño y puede determinarse mejor a través de ensayo y error, así como pruebas de juego. Una vez que todos los clientes han enviado su acción deseada, cada cliente ejecuta todas las acciones que se enviaron en el turno n + m. Esto introduce un pequeño retraso en cuando una acción es ordenada por el usuario y cuando se ejecuta, sin embargo esto no suele ser notable.

Hay varias técnicas que se pueden utilizar para falsificar el tiempo también. Por ejemplo, si resalta una unidad y luego le dice que se mueva, emitirá un sonido y tendrá una animación cuando comience a moverse, pero en realidad no se moverá de inmediato. Sin embargo, el mensaje de red de una intención de mover esa unidad se envía inmediatamente, por lo que para cuando la pantalla responda a la entrada del jugador, los mensajes de red ya se han enviado y confirmado. Usted puede fudge aún más mediante la introducción de un pequeño retraso (100ms más o menos) entre el clic del ratón y la respuesta del objeto del juego. Esto generalmente no es notable por el jugador, pero 100ms es una eternidad en un juego LAN e incluso con una conexión de banda ancha en una computadora doméstica, el ping promedio es probablemente alrededor de 15-60 ms o menos, lo que le da tiempo suficiente para enviar el paquete antes del movimiento.

En cuanto a los datos a enviar, hay dos tipos de datos en los juegos: deterministas y no deterministas. las acciones deterministas se basan en la física del juego, de modo que cuando la acción comienza, hay una garantía del 100% de que puedo predecir el resultado de esa acción. Estos datos nunca necesitan ser enviados a través de la red, ya que puedo determinar lo que será en el cliente en función del estado inicial. Tenga en cuenta que el uso de un generador de números aleatorios con la misma semilla en cada cliente convierte los eventos "aleatorios" en un comportamiento determinista. Los datos no deterministas son generalmente de entrada del usuario, pero es posible predecir lo que la entrada de un usuario es probable que sea en muchos casos. La forma en que estos pares en un juego de estrategia en tiempo real es que el evento no determinista es una especie de orden a uno de mis objetos de juego. Una vez que el objeto del juego ha sido ordenado para moverse, la forma en que se mueve es 100% determinista. Por lo tanto, todo lo que necesita enviar a la red es el ID del objeto, el comando dado (haga esto una enumeración para ahorrar ancho de banda) y el objetivo del comando (si lo hay, por lo que un hechizo puede no tener ningún objetivo si es un área de affet pero un comando move tiene un destino final). Si el usuario hace clic como 100 veces para hacer un movimiento de unidad, no hay necesidad de enviar un comando de movimiento por separado para cada clic, ya que todos están en la misma área general, así que asegúrese de filtrar esto también, ya que matará su ancho de banda.

Un último truco para manejar un posible retraso entre un comando y su ejecución es algo llamado filtro de percepción local. Si recibo una orden de movimiento algún tiempo t después de que se dio la orden, sé cuando la unidad debería haber empezado a moverse y sé su destino final. En lugar de teletransportar la unidad para llegar a donde se supone que debe estar, puedo comenzar su movimiento tarde y luego meterme con la física para acelerarla ligeramente para que pueda ponerse al día donde se supone que debe estar, y luego ralentizarla para colocarla en el lugar correcto. El valor exacto que necesita para acelerarlo también es relativo y playtesting es la única manera de determinar el valor correcto porque solo tiene que "sentirse bien" en orden para que sea correcto. Puedes hacer lo mismo disparando balas y misiles también y es altamente efectivo para eso. La razón por la que esto funciona es que los humanos no son terriblemente buenos para ver cambios sutiles en el movimiento, particularmente si un objeto se dirige directamente hacia ellos o se aleja de ellos, por lo que simplemente no se dan cuenta.

Lo siguiente que hay que pensar es reducir el ancho de banda. No envíe mensajes a clientes que no puedan ver o interactuar con una unidad que movimiento. No envíes el mismo mensaje una y otra vez porque el usuario haga clic. No envíes mensajes inmediatamente para eventos que no tengan un efecto inmediato. Por último, no se requiere un acuse de recibo para los eventos que serán obsoletos en caso de que no se reciban. Si no obtengo una actualización de movimiento, para cuando vuelva a transmitir esa actualización, su valor será tan antiguo que ya no es relevante, por lo que es mejor enviar otro movimiento y usar un filtro de percepción local para ponerse al día o usar un cúbico spline para interpolar el movimiento para que se vea más correcto o algo de esa naturaleza. Sin embargo, un evento que sea crítico, como "estás muerto" o "tu bandera ha sido tomada" debe ser reconocido y re-transmitido si es necesario. Enseño programación de juegos en red en Digipen, así que siéntete libre de hacer cualquier otra pregunta sobre esto, ya que probablemente pueda darte una respuesta. La programación de juegos en red puede ser bastante complicada, pero en última instancia se trata de tomar decisiones en su implementación y entender las consecuencias de su elección.