Diseño del motor del juego: servidores multijugador y de escucha [cerrado]

Mi motor de juego en este momento consiste en una parte funcional para un jugador. Ahora estoy empezando a pensar en cómo hacer la parte multijugador.

He descubierto que muchos juegos en realidad no tienen un modo de jugador único real, pero cuando juegas solo también estás alojando un servidor local, y casi todo funciona como si estuvieras en el modo multijugador (excepto que los paquetes de datos se pueden pasar sobre una ruta alternativa para un mejor rendimiento)

Mi motor necesitaría una gran refactorización para adaptarse a este modelo. Habría tres modos posibles: cliente dedicado, servidor dedicado y cliente-servidor (modo de escucha)

• ¿Con qué frecuencia se usa el modelo de servidor de escucha en la industria del juego?
• ¿Cuáles son las (des) ventajas de esto?
• ¿Qué otras opciones tengo?

Veré si puedo responder esto lo mejor que pueda:

¿Con qué frecuencia se usa el modelo de servidor de escucha en la industria del juego?

Cuando se trata de la mayoría de los juegos en línea, encontrarás que la gran mayoría de los juegos usan una arquitectura cliente-servidor, aunque no siempre de la manera que piensas. Tome cualquier juego de origen, por ejemplo. La mayoría utilizará un servidor cliente estándar con una arquitectura de servidor maestro (para enumerar los juegos disponibles), en el que una persona alojará un servidor dedicado y cualquiera con un cliente puede unirse a él.

Sin embargo, tiene algunos juegos y servicios, por ejemplo, Left 4 Dead, League of Legends y algunos juegos de XBox Live, que adoptan un enfoque ligeramente diferente. Todos estos utilizan una arquitectura cliente-servidor con un servidor de control. La idea principal aquí es que alguien crea un servidor dedicado que no está "ejecutando" ningún juego. El servidor de control creará una especie de "lobby", y cuando se inicie el juego, el servidor de control los agregará a una cola, y cuando sea el turno de ese lobby, seleccionará un servidor dedicado correspondiente (en términos de ubicación / velocidad, disponibilidad, numerosos factores) y asignar los jugadores a ese servidor. Solo entonces el servidor realmente "ejecutará" el juego. Es la misma idea, pero un poco simplificada, ya que el cliente no necesita "elegir" un servidor,

Por supuesto, el modelo más grande de cliente-servidor es el modelo MMO, donde uno o varios servidores ejecutan un mundo persistente que maneja casi todos los datos y la lógica. Algunos de los juegos más famosos que usan este modelo son World of Warcraft, Everquest, algo así.

Entonces, ¿dónde cabe un servidor de escucha aquí? Para ser honesto, no tan bien, sin embargo, todavía encontrarás muchos juegos que lo usan. Por ejemplo, la mayoría de los juegos de Source permiten la creación de servidores de escucha, y muchos juegos de XBox Live lo hacen (ha pasado un tiempo, pero creo que Counter Strike lo hizo, al igual que Quake 4 y muchos otros). Sin embargo, en general, parecen estar mal vistos debido a las ventajas del modelo cliente-servidor, lo que nos lleva al siguiente punto.

¿Cuáles son las (des) ventajas de esto?

Primero y principal: rendimiento. En un modelo cliente-servidor, el cliente manejará los cambios locales (como entrada, gráficos, sonidos, etc.) en cada ciclo del juego. Al final del ciclo, empaquetará datos relevantes (como, ¿se movió el jugador? Si es así, ¿a dónde? ¿Dónde está mirando ahora? ¿Velocidad? ¿Dispararon? Si es así, información sobre la bala. Etc) y envíelo al servidor para su procesamiento. El servidor tomará estos datos y determinará si todo es válido, por ejemplo, si el usuario se mueve de una manera que indica piratería (más sobre eso más adelante), ¿es válido el movimiento (algo en el camino?), La bala del jugador 1 hit player 2 ?, y más. Luego, el servidor empaqueta esto y lo envía a los clientes, que luego actualizan lo que sea necesario, como ajustar la salud si el jugador recibió un disparo, patear al jugador si se determina que están pirateando, etc.

Sin embargo, un servidor de escucha debe lidiar con todo esto al mismo tiempo. Dado que supongo que está familiarizado con la programación, probablemente se dé cuenta de la potencia que un juego puede robar de una computadora, especialmente una mal diseñada. Agregando procesamiento de red, procesamiento de seguridad y más , así como el juego del cliente, puede ver dónde el rendimiento se vería afectado, al menos en lo que respecta al procesamiento estándar. Además, la mayoría de los servidores se ejecutan en redes rápidas y son servidores diseñados para soportar el tráfico de red. Si la red de un servidor de escucha es lenta, todo el juego sufrirá.

Segunda seguridad , como se dijo anteriormente, una de las cosas principales que hará un servidor es determinar si un jugador está explotando el juego. Es posible que los haya visto como Punkbuster, VAC, etc. Hay un conjunto de reglas muy complicado que ejecuta estos programas, por ejemplo, determinando la diferencia entre un pirata informático y un muy buen jugador. Sería muy malo para tu juego si no pudieras atrapar a los piratas informáticos, pero aún peor si ejecutaras una acción contra un acusado falsamente.

Un servidor de escucha generalmente no podrá manejar el juego del cliente, el procesamiento del servidor y la detección de pirateo, y en la mayoría de los casos, los detectores como Punkbuster son muy difíciles, si no imposibles, de ejecutar en un servidor de escucha, porque es es difícil que funcione correctamente sin la potencia de procesamiento necesaria, ya que generalmente la lógica del juego tiene prioridad sobre la seguridad, y si no se permite que el detector procese para un cuadro, puede perder los datos necesarios para condenar a alguien.

Por último, jugabilidad . Lo más importante de los servidores es que son persistentes, lo que significa que incluso si todos se van, el servidor continuará ejecutándose. Esto es útil si tiene un servidor popular que no tiene mucha actividad durante la noche, las personas aún pueden unirse cuando están listas para jugar y no tienen que esperar a que vuelva a estar en línea.

En un servidor de escucha, la principal desventaja es que tan pronto como el cliente que aloja el servidor de escucha se va, el juego debe ser transferido a otro jugador (creando un lul en el juego que puede durar minutos en algunos casos), o debe terminar por completo . Esto no es preferible en un servidor grande, ya que el host debe permanecer conectado (desperdiciando una ranura en el servidor y la potencia de su computadora, lo que también podría ralentizar el juego), o finalizar el juego para todos.

Sin embargo, a pesar de estos problemas, los servidores de escucha tienen algunas ventajas.

Fácil de configurar : la mayoría de los servidores de escucha no son más que presionar "Nuevo juego" y dejar que la gente se una. Esto es fácil para las personas que solo quieren jugar con sus amigos y no desean tener que buscar un servidor dedicado vacío o jugar con otras personas.

Bueno para probar : si uno posee un servidor dedicado y desea cambiar su configuración, generalmente es una mejor idea probarLa configuración primero. El usuario tendría que crear una copia de seguridad del servidor dedicado e ir ciegamente a los cambios, con la única opción de retroceder si algo sale mal, crear un nuevo servidor dedicado para probarlos, o simplemente crear un servidor de escucha simple para pruébalos. Y con el punto 1, estos son generalmente más fáciles de iniciar y configurar. Esto es especialmente cierto, ya que la mayoría de los servidores dedicados no están dentro del acceso inmediato de los administradores (la mayoría de los servidores dedicados se alquilan desde una ubicación remota). Lleva mucho más tiempo llevar los cambios de configuración, así como los comandos para reiniciar, etc., a una ubicación remota que a una máquina en la que se encuentra actualmente el administrador.

Menos recursos : en la mayoría de los servidores dedicados, un usuario con la misma IP no puede conectarse al servidor dedicado (lo que significa que el cliente debe alojar el servidor o jugar, no pueden hacer ambas cosas). Si el cliente desea jugar en su propio servidor, generalmente necesitará una segunda máquina para alojar el servidor, o comprar o alquilar un servidor dedicado para poder jugar en él. Un servidor de escucha requiere solo una máquina, que puede ser lo único que el cliente puede usar.

En cualquier caso, ambos tienen ventajas y desventajas, y debe sopesarlos con lo que está dispuesto a diseñar e implementar. Desde mi experiencia, creo que si implementara un servidor de escucha, se utilizaría, para nada más que para unos pocos usuarios que desean jugar con amigos o probar la configuración.

Por último:

¿Qué otras opciones tengo?

Esta es una lata industrial de gusanos. En realidad, cualquier tipo de arquitectura de red se puede aplicar a los videojuegos. Sin embargo, por lo que he visto, como la mayoría de las comunicaciones por Internet, la mayoría se reduce a alguna forma de modelo cliente-servidor.

Avíseme si no respondí su pregunta, o si necesita algo ampliado, y veré qué puedo hacer.