¿Cómo puedo hacer un juego multijugador entre pares? [cerrado]

¿Cómo puedo hacer un juego multijugador p2p? Me gustaría tener un juego multijugador sin servidor. Pero entonces, ¿cómo se conocen todos los clientes?

¿Por qué el protocolo p2p es tan famoso en la transferencia de archivos pero no en los juegos multijugador?

Los juegos entre pares generalmente todavía tienen un host de juegos. Es el anfitrión del juego el que publica el juego en la lista maestra de juegos y acepta nuevas conexiones. Cada vez que el anfitrión del juego acepta un nuevo cliente para el juego, notifica a todos los clientes existentes sobre el nuevo cliente para que puedan asegurarse de que se conectan al nuevo cliente.

La forma más sencilla de implementar p2p es con un lobby. Todos los clientes se conectan al host en un lobby (o sala de chat). Cuando el anfitrión está listo, el jugador presiona Inicio y todos entran al juego al mismo tiempo (comúnmente utilizado en juegos de estrategia). Un enfoque más complejo es usar "drop-in drop-out" donde los jugadores pueden unirse y salir del juego, sin embargo, esto es mucho más complejo de implementar en un juego p2p y requiere una característica llamada migración de host.

Un buen número de juegos utiliza redes de igual a igual, incluyendo la mayoría de los títulos de estrategia, deportes y conducción. Casi todos los juegos de Xbox360 y PS3 usan redes p2p. La arquitectura cliente-servidor se usa principalmente en juegos de disparos en primera persona o juegos MMO.

El cliente-servidor es generalmente más fácil de implementar, ya que solo 1 máquina no conoce todo el estado del juego, los clientes son básicamente renderizadores con algunas predicciones para que las cosas se vean sin problemas.

Cuando construyes un motor p2p, todos los clientes necesitan un estado completo del mundo del juego y todos deben permanecer sincronizados.

Para obtener más detalles sobre las arquitecturas p2p y cliente-servidor, le sugiero que lea el siguiente artículo: Lo que todo programador necesita saber sobre las redes de juegos .

Y si eres nuevo en las redes en general, revisa los otros excelentes artículos en ese sitio. Glenn es un genio de las redes.

Hay muchas razones por las que p2p no es popular en los juegos, principalmente debido al retraso. Todos son tan lentos como el jugador más lento. No estamos hablando del ancho de banda aquí, sino del tiempo de ping.

p2p puede transferir toneladas de datos, pero lo hace con un ping bastante alto, los juegos necesitan transmitir cantidades muy pequeñas de datos, con un tiempo de ping mínimo.

Hay algunos aspectos interesantes sobre los sistemas de igual a igual y los juegos de acción. Traté de publicarlos como un comentario en el blog de Glenn Fiedler, pero aparentemente no le gusta que se demuestre que está equivocado y en su lugar sacó todo el artículo. Está en Internet Archive, en caso de que quiera leerlo.

No dejó que el comentario se pusiera en línea, así que lo citaré aquí:

La sugerencia punto a punto de la primera publicación es en realidad un punto de partida interesante, aunque a veces es un poco ingenuo: la primera posibilidad sería combinar el sistema con un modelo estándar de cliente / servidor con predicción como se describe en su publicación sobre redes de juegos. El ping P2P más bajo reduciría drásticamente el retraso de predicción entre los jugadores dependiendo de su ubicación: el efecto probablemente no sería visible para la mayoría de los jugadores estadounidenses, pero aquí en Europa los pings de más de 200 son normales en la mayoría de los servidores y una conexión directa reduciría el retraso de predicción al de un servidor europeo.

Un verdadero enfoque P2P sin servidor es un poco más complejo: una preocupación principal con las redes descentralizadas es garantizar la coherencia, especialmente si la simulación podría sufrir efectos de mariposa debido a una sincronización ligeramente diferente de los comandos enviados a través de la red o problemas de punto flotante. Esto es posible conectando en red el estado de cada objeto (jugadores, NPC, ...) al menos periódicamente. Ni siquiera sería necesario hacerlo para todos los objetos a la vez, y cada cliente podría tomar posesión de ciertos objetos. La conexión en red de suficientes objetos en un tiempo determinado debería amortiguar la diferencia que se acumula entre cada sincronización de un objeto lo suficiente como para volverse irrelevante incluso para intervalos de sincronización de un segundo o más.

El segundo problema con los sistemas P2P es la seguridad, pero en este caso se puede resolver con una solución relativamente pequeña: los clientes pueden usar sus simulaciones físicas para recopilar información sobre el nivel de error en cada objeto físico. La física manipulada siempre produce un error mayor, por lo que los clientes simplemente "votarían" para desconectarse del par que controla un objeto sospechoso. Además, los mensajes de control para objetos no físicos se reenvían entre los clientes en función de su importancia: las actualizaciones de los jugadores se pueden reenviar aleatoriamente, las actualizaciones importantes y poco frecuentes siempre se deben enviar, pero aún así a un jugador aleatorio. De esta manera, un jugador tendría que controlar una gran parte de los clientes conectados para poder hacer trampa de cualquier manera notable.

[...]

Puede encontrar el hilo al que me refiero en http://www.devmaster.net/forums/showthread.php?t=14640 .

Creo que alguien mencionó los problemas de firewall que tiene uno a otro en uno de los hilos del artículo. Una posible solución sería un NAT-Punchthrough:
- Descripción general de NAT Punchthrough
- Comunicación punto a punto a través de traductores de direcciones de red

No hay una tasa de éxito del 100%, por lo que debes decirles a los jugadores que abran un puerto de todos modos.

Un buen ejemplo de juego 'verdadero de igual a igual' sería un juego de estrategia en tiempo real como Starcraft.

En un juego con cientos de unidades / proyectiles en movimiento, no es práctico enviar repetidamente posiciones / estados de la unidad a través de la red a todos los demás jugadores, por lo que una solución aquí es que todos los jugadores ejecuten la simulación (exactamente la misma) en sincronización.

Cuando un jugador realiza una acción, el comando / orden ('mover zergling a X, Y') se puede enviar a todos los demás jugadores, para que se ejecuten en todas las instancias de la simulación una fracción de segundo más tarde.

En esta situación, si algún jugador se desconecta, el juego puede continuar, ya que no hay necesidad de que un servidor / host esté ejecutando el juego, los jugadores restantes pueden continuar.

Sin embargo, mantener los juegos sincronizados no es trivial, debe usar un paso de tiempo fijo para las actualizaciones lógicas del juego, y debe tener mucho cuidado con el uso y la generación de generadores de números aleatorios, para asegurarse de que las simulaciones no diverjan.

Sería un poco falso decir que no es famoso por los juegos cuando la mayoría de los juegos de estrategia en tiempo real (serie Star Craft, serie Command and Conquer) y muchos juegos FPS (Call of Duty: Modern Warfare 2) lo usan.

Dicho esto, la forma en que uno aprende sobre el juego depende del servicio de emparejamiento / lobby que use o cree. Pero incluso una vez que uno aprende sobre el juego, aún puede haber uno o más compañeros que sean más iguales que otros. Considere el caso de 3 clientes que desean jugar, uno detrás de un nat abierto, 2 detrás de un estricto (Cerrado) nats. El Open Nat Peer puede tomar conexiones de los otros dos. Pero los 2 estrictos no pueden conectarse directamente entre sí, requerirán la nat abierta para retransmitir los paquetes. Si el jugador natural abierto cae del juego, entonces será necesario encontrar otro relevo o se interrumpirá el juego.

También puede visitar Badumna (www.badumna.com), que afirma ser una solución de red punto a punto para juegos en línea. Parece hacer la sincronización del estado del juego de manera distribuida y de acuerdo con su sitio web hay una versión Flash próxima.

Probablemente quieras correr con un jugador (lo llamaremos el "Host") como un servidor no autorizado. Hará que todos los demás jugadores comuniquen lo que están haciendo con nuestro anfitrión, y el anfitrión transmitirá los mensajes a los otros jugadores.

Probablemente también desee pasar una lista de qué computadoras están conectadas al reproductor de alojamiento para que, si se caen, se pueda elegir un nuevo host de alguna manera y comenzar a comunicarse con los jugadores restantes.

La documentación para smartfoxserver puede ayudarte y / o puedes terminar queriendo usarla también para tu juego. Simplemente lo incrustaría en su juego de cliente en lugar de tener un programa de cliente y servidor separado.

Estoy un poco interesado en este asunto. Estás diciendo que hay muchos problemas para hacer un juego p2p en lugar de un modelo clásico de cliente-servidor. Pero estoy bastante seguro de que p2p es como cliente-servidor, pero cada par tiene la oportunidad de convertirse en un servidor. Sobre el LAG si agrega una máquina más como servidor, hay más probabilidades de que muchos clientes estén más lejos del servidor, pero al usar p2p no hay máquinas adicionales en el lobby, puede administrar las pruebas de latencia y crear grupos con un ping mínimo. Acerca de la generación de tráfico, como he aprendido, debe pedir a los clientes que transmitan menos que menos, quiero decir que los clientes tienen que darse cuenta de que todos los demás clientes están dispuestos a hacerlo.

Si está creando un mmorpg de aspecto relativamente simple con bajos requisitos del sistema, le sugiero que cree un programa interno que cree una "frecuencia" basada en el contenido de la carpeta del juego y en qué consisten los archivos. Esto hará que las personas con la misma "frecuencia" jueguen en los mismos canales. Los clientes modificados, manipulados o normales serán separados. Esto solo funcionará para hacks o mods nativos, pero estoy seguro de que esto cubre a todos los tramposos "tontos". Combinado con el método de verificación de errores que mencionó una persona significa que se requiere poca o ninguna moderación. En cuanto a los puertos, simplemente haga que cubra el puerto 52225 con un proceso en segundo plano que lo mantenga conectado a los enrutadores sin puertos de activación.