sockets - sala - ¿Qué tipo de problemas hay en la implementación de juegos multijugador en tiempo real?

cómo jugar halo 5 de 2 jugadores en la misma consola (5)

¿Qué tan importante es evitar hacer trampa? [¿Puedes confiar en la información que proviene de un cliente o pueden confiar y autenticarse?]

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

¿Estás haciendo cliente / servidor o de igual a igual?

Números aleatorios Si hace un par a par, debe mantenerlos bloqueados y los números aleatorios sincronizados.

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

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

Echa un vistazo a RakNet, es gratis para descargar el código y sus grupos de discusión.

Tengo algo de experiencia haciendo juegos basados en turnos para varios jugadores usando sockets, pero nunca he intentado un juego de acción en tiempo real. ¿Con qué tipo de problemas adicionales tendría que lidiar? ¿Debo 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 bastará con TCP? ¿Qué más?

Realmente no he decidido qué hacer, pero para el propósito de esta pregunta puedes considerar un juego 2D de 10 jugadores con movimiento XY.

Hay algunos factores relacionados con la configuración del modo multijugador

El protocolo, es importante que decidas si quieres TCP o UDP. UDP tiene menos sobrecarga pero no garantiza la entrega. Por el contrario, TCP es más confiable. Cada juego tendrá su protocolo preferido. UDP, por ejemplo, funcionará para un tirador en primera persona, pero puede no ser adecuado para un RTS donde la información debe ser consistente
Firewall / Conexión. Asegurándose de que su juego multijugador no tenga que realizar 2000 conexiones salientes y use un puerto estándar para que sea fácil el traspaso. Interconectarlo con el firewall de Windows probablemente sea una ventaja adicional.
Ancho de banda Esto es importante, ¿cuántos datos pretendes utilizar a través de una conexión de red? Supongo que esto se reducirá a las pruebas y el rendimiento de la grabación. Si necesita más de 200kb / s para cada cliente, puede reconsiderar algunas cosas.
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 montones más, pero realmente quieres un juego que sea cómodo de jugar en la red y en una variedad de conexiones.

La planificación es tu mejor amigo. Descubre cuáles son tus necesidades realmente.

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á que mover estos datos.

Hacer trampa: ¿tienes que preocuparte? ¿Puedes confiar en lo que cada cliente está diciendo? Si no, entonces la lógica del servidor se verá diferente a la lógica del lado del cliente. Imagina este simple caso, cada uno de tus 10 jugadores puede tener una velocidad de movimiento diferente debido a los power-ups. 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 hackear la aceleración y nada los detendría. Si un jugador es consistentemente un poco más rápido de lo esperado o tiene un salto de una vez, el servidor simplemente los reposicionaría en la ubicación más cercana posible, porque es probable que el reloj se tuerza o una interrupción de comunicación por única vez. Sin embargo, si un jugador se mueve constantemente dos veces tanto como sea posible, puede ser prudente expulsarlo del juego. Cuantas más matemáticas, más partes del estado del juego puedes verificar en el servidor, mientras más consistente sea el juego, de paso esto hará que sea más difícil hacer trampa.

Cómo es de igual a igual: incluso si el juego será de igual a igual, es probable que desee que un jugador inicie un juego y lo use como servidor, esto es mucho más fácil que tratar de administrar algunos de los más basados en la nube. enfoques. Si no hay servidor, entonces necesita trabajar un protocolo para resolver disputas entre 2 máquinas con estados de juego inconsistentes.

Una vez más, la planificación es su mejor amigo Plan, Plan, Plan. Si piensas en un problema lo suficiente, puedes pensar en la mayoría de los problemas. Entonces puedes comenzar a pensar en los que aún no has resuelto.

TCP está bien si se ejecuta en una LAN. Pero si quiere jugar en línea, debe usar UDP e implementar su propia capa tipo TCP: es necesario pasar los 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 carezca de reactividad en línea. En Pee-to-peer es más complicado, pero más rápido para el jugador.

No mantenga la historia de la acción del jugador para el propósito del juego (hágalo, pero solo para la funcionalidad de reproducción). Si llegas a un punto donde es necesario, prefiere que todos los jugadores esperen.

''servidor de cliente'' o ''de igual a igual'' o algo intermedio: qué computadora tiene autoridad sobre qué acciones del juego.

Con los juegos por turnos, normalmente es muy fácil decir ''el servidor tiene la máxima autoridad y hemos terminado''. Con los juegos en tiempo real, a menudo ese diseño es un gran lugar para comenzar, pero tan pronto como agrega latencia, el movimiento / acciones del cliente no responde. Así que agregas algún tipo de "latencia escondida" que permite que los comentarios de los clientes afecten a su personaje o unidades de inmediato para resolver ese problema, y ahora tienes que lidiar con problemas de reconciliación cuando el cliente y los servidores del estado del juego comienzan a divergir. 9 veces fuera de 10 que está bien, abre o mueve los objetos que el cliente ha afectado a la posición de autoridad, pero que 1 de cada 10 veces es cuando el objeto es el avatar del jugador o algo, esa solución es inaceptable, por lo que comienza darle al cliente autoridad sobre algunas acciones. Ahora tiene que reconciliar los múltiples estados de juegos en el servidor y abrirse a un posible "engaño" a través de un cliente malintencionado, si le importa ese tipo de cosas. Esto es básicamente donde aparece cada error / trampa de teletransporte / engaño / lo que sea.

Por supuesto, podrías comenzar con un modelo donde ''cada cliente tenga autoridad sobre'' sus ''objetos'' e ignorar el problema de trampas (bueno 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 para seguir con la simulación"; de hecho, cada juego de los jugadores terminará siendo / sintiendo los efectos de un retraso o rendimiento insuficiente del cliente, en forma de esperar a que el cliente rezagado se ponga al día, o tener el estado del juego que controlan fuera de sincronización.

''sincronizado'' o ''asincrónico''

Una estrategia común para asegurar que todos los jugadores estén operando en el mismo estado de juego es simplemente acordar la lista de entradas de jugadores (a través de uno de los modelos descritos anteriormente) y luego hacer que la simulación del juego se desarrolle sincronizadamente en todas las máquinas. Esto significa que la lógica de simulación tiene que coincidir exactamente, o los juegos se desincronizarán. Esto es realmente 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 prácticamente ejecuta exactamente lo mismo cuando da la misma entrada (incluso generadores de números aleatorios). Es más difícil porque hay dos casos en los que no es el caso: (1) cuando accidentalmente usas aleatoriamente fuera de tu simulación de juego y (2) cuando usas flotadores. El primero se rectifica al tener reglas / afirmaciones estrictas sobre qué RNG son utilizados por qué sistemas de juego. Esto último se resuelve al no usar flotadores. (las carrozas en realidad tienen 2 problemas, uno funciona de forma muy diferente en función de la configuración de optimización de su proyecto, pero incluso si eso se resolvió, funcionan de manera incoherente en diferentes arquitecturas de procesador atm, lol). Starcraft / Warcraft y cualquier juego que ofrezca una "repetición" probablemente utilicen este modelo. De hecho, tener un sistema de reproducción es una excelente forma de probar que tus RNG se mantengan sincronizados.

Con una solución asíncrona, las autoridades del estado del juego simplemente transmiten ese estado completo a todos los demás clientes con cierta frecuencia. Los clientes toman esa información y la envían a su estado de juego (y normalmente hacen una extrapolación simplista hasta que obtengan la próxima actualización). Aquí es donde ''udp'' se convierte en una opción viable, ya que está enviando correo basura a todo el estado del juego cada ~ 1seg más o menos, dejar caer una fracción de esas actualizaciones es irrelevante. Para los juegos que tienen relativamente poco estado de juego (terremoto, World of Warcraft), esta es a menudo la solución más simple.