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

juegos de estrategia para pc pocos requisitos

Question

Estoy interesado en cómo funcionan los protocolos (y el bucle del juego) para este tipo de juegos; cualquier puntero o idea son apreciados.

Supongo que el ciclo principal tendría un estado mundial que avanzaría unos pocos "tics" por segundo, pero ¿cómo se ejecutan los comandos de los jugadores? ¿Qué tipo de información necesita ir y venir?

Answer 1

Discusión de la arquitectura de red de Age of Empires here

En mi humilde opinión, ese estilo de arquitectura basada en repeticiones duplicadas peer-to-peer es impresionante, pero un poco sin salida para algo más de 8 o más jugadores.

Answer 2

Echa un vistazo a Battle for Wesnoth.

http://www.wesnoth.org/

Es gratis, de código abierto y totalmente increíble. Puedes aprender mucho de profundizar en su fuente.

Answer 3

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 tus preguntas. Aquí hay un resumen: Primero, la mayoría de los juegos usan UDP debido a la naturaleza en tiempo real del juego. El lazo del juego se ve así:

1. leer datos de red
2. hacer predicciones del lado del cliente y comparar con el lugar donde la red dice que tus objetos deberían ser
3. meterse con la física para eludir lo que dice la red con lo que es el estado de tu juego local
4. enviar datos de vuelta a la red en función de lo que hizo este marco (si acaso)
5. hacer

Esto se simplifica enormemente y "meterse con la física" podría ser un libro de 200 páginas por sí mismo, pero implica predecir el lado del cliente donde es probable que haya algo, obtener datos del servidor que es antiguo pero decir exactamente dónde estaba / debería un objeto ser, y luego interpolar esos valores de alguna manera para hacer que el objeto aparezca "lo suficientemente cerca" de donde se supone que debe estar, que nadie lo nota. 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 suele pasar es un sistema por turnos donde el tiempo se divide en fragmentos discretos llamados "giros" que suceden secuencialmente y cada turno tiene un número generado por una función monótona que garantiza valores cada vez mayores en un orden particular sin duplicados En cualquier turno dado n, cada cliente envía un mensaje a todos los demás clientes con su acción prevista en turno n + m, donde m es un número arbitrario que suele ser bastante pequeño y puede determinarse mejor mediante prueba y error, así como con pruebas de prueba. Una vez que todos los clientes han enviado su acción prevista, cada cliente ejecuta todas las acciones que se enviaron el turno n + m. Esto introduce una pequeña demora en cuando el usuario ordena una acción y cuando se ejecuta, sin embargo, esto generalmente no es notorio.

Hay varias técnicas que se pueden utilizar para burlar el tiempo también. Por ejemplo, si resaltas una unidad y luego le dices que se mueva, emitirá un sonido y una animación cuando empiece a moverse, pero no se moverá de inmediato. Sin embargo, el mensaje de red de un intento de mover esa unidad se envía inmediatamente, de modo que cuando la pantalla responde a la entrada del jugador, los mensajes de red ya han sido enviados y confirmados. Puede cambiar el color introduciendo un pequeño retraso (100 ms o menos) entre el clic del mouse y la respuesta del objeto del juego. Esto generalmente no es notificable por el jugador, pero 100ms es una eternidad en un juego de LAN e incluso con una conexión de banda ancha en una computadora hogareña, el promedio de ping es probablemente de alrededor de 15-60ms o más, lo que le da mucho tiempo para enviar el paquete antes de el movimiento.

En cuanto a los datos a enviar, existen dos tipos de datos en los juegos: deterministas y no deterministas. las acciones deterministas se basan en la física del juego para que cuando comience la acción, haya una garantía del 100% de que puedo predecir el resultado de esa acción. Esta información nunca necesita ser enviada a través de la red ya que puedo determinar qué 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 suelen ser ingresados ​​por el usuario, pero es posible predecir cuál será la entrada de un usuario en muchos casos. La forma en que estas parejas en un juego de estrategia en tiempo real es que el evento no determinista es una especie de orden para 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 en la red es el ID del objeto, el comando dado (hacer de esto una enumeración para ahorrar ancho de banda) y el objetivo del comando (si hay alguno, por lo que un hechizo puede no tener objetivo si es un área de affet pero un comando de movimiento tiene un destino final). Si el usuario hace clic 100 veces para hacer que una unidad se mueva, no hay necesidad de enviar un comando de movimiento diferente para cada clic, ya que todos están en el mismo área general, así que asegúrese de filtrar esto también, ya que matará a su ancho de banda

Un truco final 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 un tiempo t después de la orden, sé cuándo la unidad debería haber comenzado a moverse y sé cuál es su destino final. En lugar de teletransportar la unidad para llevarla a donde se supone que debe estar, puedo comenzar su movimiento tarde y luego meterme con la física para acelerarla un poco, de modo que pueda alcanzar hasta donde se supone que debe estar, y luego reducirla hasta reducirla a ponlo en el lugar correcto. El valor exacto que necesita para acelerarlo también es relativo y la prueba de juego es la única forma de determinar el valor correcto, ya que solo tiene que "sentirse bien" para que sea correcto. Puedes hacer lo mismo disparando balas y misiles también y es muy 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 lejos 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 podrían ver o interactuar con una unidad que se está moviendo. No envíe el mismo mensaje una y otra vez porque el usuario hace clic. No envíe mensajes de inmediato para eventos que no tengan un efecto inmediato. Finalmente, no requiera un reconocimiento de los eventos que quedarán obsoletos si no se reciben. Si no recibo una actualización de movimiento, cuando vuelva a transmitir esa actualización, su valor será tan antiguo que ya no es relevante, así que es mejor simplemente enviar otro movimiento y usar un filtro de percepción local para ponerse al día o usar una spline cúbica para interpolar el movimiento para que se vea más correcto o algo de esa naturaleza. Sin embargo, un evento que es crítico, como "estás muerto" o "tu bandera ha sido tomada" debería ser reconocido y retransmitido si es necesario. Enseño programación de juegos en red en Digipen, así que siéntete libre de hacerme cualquier otra pregunta sobre esto ya que probablemente pueda darte una respuesta. La programación de juegos en red puede ser bastante complicada, pero al final se trata de tomar decisiones sobre su implementación y comprender las consecuencias de su elección.