¿Qué tipo de problemas existen al implementar juegos multijugador en tiempo real?

Question

Tengo algo de experiencia haciendo multijugador. por turnos juegos que usan sockets, pero nunca he probado un juego de acción en tiempo real.¿Con qué tipo de problemas adicionales tendría que lidiar?¿Necesito mantener un historial de las acciones de los jugadores en caso de que los jugadores rezagados hagan algo en el pasado?¿Realmente necesito usar paquetes UDP o será suficiente TCP?¿Qué otra cosa?

Realmente no he decidido qué hacer, pero para esta pregunta puedes considerar un juego 2D para 10 jugadores con movimiento X Y.

Answer 1

• 'servidor cliente' o 'peer to peer' o algo intermedio:qué computadora tiene autoridad sobre qué acciones del juego.

Con los juegos por turnos, normalmente es muy fácil decir simplemente "el servidor tiene la máxima autoridad y listo".Con los juegos en tiempo real, a menudo ese diseño es un excelente punto de partida, pero tan pronto como agregas latencia, los movimientos/acciones del cliente parecen no responder.Entonces agregas algún tipo de 'ocultación de latencia' que permite que la entrada del cliente afecte a su personaje o unidades inmediatamente para resolver ese problema, y ​​ahora tienes que lidiar con los problemas de conciliación cuando el estado del juego del cliente y del servidor comienza a divergir.9 de cada 10 veces está bien, haces estallar o arrastras los objetos que el cliente ha afectado a la posición autoritaria, pero 1 de cada 10 veces es cuando el objeto es el avatar del jugador o algo así, esa solución es inaceptable, así que comienzas. Dar al cliente autoridad sobre algunas acciones.Ahora tienes que reconciliar los múltiples estados del juego en el servidor y exponerte a una posible "trampa" a través de un cliente malicioso, si te importa ese tipo de cosas.Aquí es básicamente donde surge cada teletransporte/duplicación/cualquier error/trampa.

Por supuesto, se podría comenzar con un modelo en el que 'cada cliente tiene autoridad sobre 'sus' objetos' e ignorar el problema de las trampas (bien en bastantes casos).Pero ahora eres vulnerable a un efecto masivo en la simulación del juego si ese cliente abandona, o incluso "simplemente se queda un poco atrás en mantenerse al día con la simulación" - efectivamente, el juego de cada jugador terminará siendo/sintiendo los efectos de una cliente retrasado o de otro modo con bajo rendimiento, ya sea en la forma de esperar a que el cliente retrasado se ponga al día o tener el estado del juego que controlan fuera de sincronización.

• 'sincronizado' o 'asíncrono'

Una estrategia común para garantizar que todos los jugadores operen en el mismo estado de juego es simplemente acordar la lista de entradas de los jugadores (a través de uno de los modelos descritos anteriormente) y luego hacer que la simulación del juego se desarrolle sincrónicamente en todas las máquinas.Esto significa que la lógica de la simulación debe coincidir exactamente, o los juegos no estarán sincronizados.En realidad, esto es más fácil y más difícil de lo que parece.Es más fácil porque un juego es solo código, y el código se ejecuta prácticamente igual cuando se le da la misma entrada (incluso generadores de números aleatorios).Es más difícil porque hay dos casos en los que ese no es el caso:(1) cuando accidentalmente usas aleatorio fuera de tu simulación de juego y (2) cuando usas flotadores.Lo primero se rectifica al tener reglas/afirmaciones estrictas sobre qué RNG son utilizados por qué sistemas de juego.Esto último se soluciona al no utilizar flotadores.(Los flotadores en realidad tienen 2 problemas, uno funciona de manera muy diferente según la configuración de optimización de su proyecto, pero incluso si eso se solucionó, funcionan de manera inconsistente en diferentes arquitecturas de procesador, jajaja).Starcraft/Warcraft y cualquier juego que ofrezca una "repetición" probablemente utilice este modelo.De hecho, tener un sistema de repetición es una excelente manera de probar que sus RNG se mantienen sincronizados.

Con una solución asíncrona, las autoridades estatales del juego simplemente transmiten ese estado completo a todos los demás clientes con cierta frecuencia.Los clientes toman esos datos y los introducen en su estado de juego (y normalmente hacen una extrapolación simplista hasta que obtienen la próxima actualización).Aquí es donde 'udp' se convierte en una opción viable, porque estás enviando spam a todo el estado del juego cada aproximadamente 1 segundo, descartar una fracción de esas actualizaciones es irrelevante.Para juegos que tienen relativamente poco estado de juego (quake, world of warcraft), esta suele ser la solución más sencilla.

Answer 2

Hay algunos factores involucrados en la configuración del modo multijugador.

1. El protocolo, es importante que decidas si quieres TCP o UDP.UDP tiene menos gastos generales pero no se garantiza la entrega.Por el contrario, TCP es más confiable.Cada juego tendrá su protocolo preferido.UDP, por ejemplo, funcionará para un juego de disparos en primera persona, pero puede no ser adecuado para un RTS donde la información debe ser coherente.

2. Cortafuegos/Conexión.Asegúrate de que tu juego multijugador no tenga que realizar 2000 conexiones salientes y utilice un puerto estándar para que el reenvío de puertos sea fácil.Conectarlo con el firewall de Windows probablemente será una ventaja adicional.

3. Banda ancha.Esto es importante: ¿cuántos datos pretende enviar a través de una conexión de red?Supongo que esto se reducirá al rendimiento de las pruebas y la grabación.Si necesita más de 200 kb/s para cada cliente, es posible que desee reconsiderar algunas cosas.

4. Carga del servidor.Esto también es importante: ¿cuánto procesamiento requiere un servidor para un juego normal?¿Necesita algún servidor super 8 core con 16 GB de RAM para ejecutarlo?¿Hay formas de reducirlo?

Supongo que hay muchos más, pero lo que realmente quieres es un juego que sea cómodo de jugar en la red y con una variedad de conexiones.

Answer 3

La planificación es tu mejor amiga.Descubra cuáles son realmente sus necesidades.

Cargando datos:¿Todas las computadoras tendrán los mismos modelos y gráficos, y solo los nombres y ubicaciones se moverán a través de la red?Si cada jugador puede personalizar su personaje u otros elementos, tendrás que mover estos datos.

Infiel:¿tienes que preocuparte por eso?¿Puedes confiar en lo que dice cada cliente?De lo contrario, la lógica del lado del servidor se verá diferente a la lógica del lado del cliente.Imagina este caso simple, cada uno de tus 10 jugadores puede tener una velocidad de movimiento diferente debido a los potenciadores.Para minimizar las trampas, debes calcular qué tan lejos puede moverse cada jugador entre las actualizaciones de comunicación del servidor; de lo contrario, un jugador podría piratear la velocidad y nada lo detendría.Si un jugador es consistentemente un poco más rápido de lo esperado o tiene un salto único, el servidor simplemente lo reposicionaría en la ubicación más cercana posible, porque es probable que se trate de un desfase del reloj o una interrupción única en las comunicaciones.Sin embargo, si un jugador se mueve constantemente el doble de lejos posible, puede ser prudente expulsarlo del juego.Cuantas más matemáticas y más partes del estado del juego puedas verificar en el servidor, más consistente será el juego; dicho sea de paso, esto hará que hacer trampa sea más difícil.

¿Qué tan peer to peer es?Incluso si el juego va a ser de igual a igual, probablemente querrás que un jugador inicie un juego y lo use como servidor; esto es mucho más fácil que intentar administrar algunos de los enfoques más basados ​​en la nube.Si no hay un servidor, entonces necesitas trabajar en un protocolo para resolver disputas entre 2 máquinas con estados de juego inconsistentes.

Nuevamente la planificación es tu mejor amiga Planificar, Planificar, Planificar.Si piensas lo suficiente en un problema, podrás resolver la mayoría de los problemas.Entonces podrás empezar a pensar en los que aún no has resuelto.

Answer 4

¿Qué tan importante es evitar hacer trampa?[¿Puede confiar en la información proveniente de un cliente o se puede confiar en ella y autenticarla?]

modelo de objetos¿Cómo se comunican los objetos de una máquina a otra?¿Cómo se llevan a cabo las acciones sobre un objeto?

¿Estás haciendo cliente/servidor o peer to peer?

Números al azarSi realiza una conexión de igual a igual, deberá mantenerlos bloqueados y los números aleatorios sincronizados.

Si está haciendo cliente/servidor, ¿cómo maneja el retraso?[¿estimación?]

Hay muchos problemas no triviales involucrados en la codificación de redes.

Echa un vistazo a RakNet, su código de descarga gratuita y sus grupos de discusión.

Answer 5

TCP está bien si lo ejecuta en una LAN.Pero si quieres jugar en línea, debes usar UDP e implementar tu propia capa similar a TCP:es necesario pasar enrutadores NAT.

Debe elegir entre comunicación punto a punto o cliente-servidor.En el modelo Cliente-Servidor, la sincronización y el estado del mundo son más fáciles de implementar, pero es posible que tenga falta de reactividad en línea.En Pee-to-peer es más complicado, pero más rápido para el jugador.

No guardes el historial de acciones del jugador para fines del juego (hazlo, pero solo para la funcionalidad de repetición).Si llegas a un punto en el que es necesario, prefieres hacer esperar a todos los jugadores.