significado - Juego multijugador con back-end y front-end de JavaScript. ¿Cuáles son las mejores prácticas?

lenguajes backend

Question

Estoy pensando en crear un juego web multijugador en Node.js. Esto significa que usaré el mismo idioma en el backend y en la interfaz. Sería en tiempo real y con un máximo de 20 personas en cada "habitación", así que tengo algunas reflexiones:

1. ¿Cómo compenso la demora entre todos los usuarios para que todos vean lo mismo al mismo tiempo? Estoy pensando en rastrear el tiempo promedio de ping de cada jugador, encontrar el más lento e informar a los otros clientes del tiempo (en milisegundos) que deben retrasarse para que todos estén tan sincronizados como sea posible.

2. Estoy pensando en ejecutar el código del juego tanto en el backend como en el frontend (ya que es JavaScript en ambos extremos) y solo tengo un mecanismo de corrección de errores para sincronizar con el ''juego real'' en el back-end. De esta forma, el juego debería funcionar sin problemas en la interfaz y con solo algunas fallas técnicas cuando ocurre la sincronización. También eso minimizaría el pirateo de JavaScript de frontend ya que los tramposos se sincronizarían hasta el juego de back-end.

3. Si recibo acciones de jugador a través del socket (presionar teclas), informar a todos los demás clientes de las acciones de los otros jugadores y mientras tanto ''jugar'' el juego en el backend y enviar información de sincronización a todos los jugadores de todo el estado de juego de una vez en un mientras que para sincronizarlos?

¿Qué piensas? ¿Hay más cosas que debería considerar o prestar atención?

Por favor, publique cualquier pensamiento o enlace a documentación o artículos sobre juegos multijugador.

EDITAR: Estos son útiles:

• Gaffer en juegos - Muy buenos artículos de Glenn Fiedler sobre redes de juego de jugadores múltiples y física
• El modelo de redes Quake3

Answer 1

1. Este es muy difícil de hacer, y puedo ver muchos problemas al sincronizar con ''el más lento''. ¿Puedes relajar esto para que los clientes puedan ser ''finalmente consistentes''?

2. Suena bien.

3. Enviaría eventos de acción breves de los frontales al back-end, haría que el backend modificara el estado del juego y publicaría los eventos de modificación del estado del juego de nuevo a los clientes, prestando mucha atención a solo enviar los eventos necesarios a los suscriptores correctos. En este punto, puedes descartar cualquier evento que no parezca coincidir o que parezca falso / piratear.

Answer 2

1 - es imposible. No sabe exactamente cuánto tardará un mensaje en llegar a un cliente y ninguna medición que tome se aplicará necesariamente al próximo mensaje que envíe. Lo mejor que puede hacer es una aproximación, pero siempre debe suponer que la gente verá O BIEN cosas ligeramente diferentes O las mismas cosas en tiempos ligeramente diferentes. Recomiendo simplemente enviar el estado actual a todos y usar la interpolación / extrapolación para suavizar la jugabilidad, de modo que todos vean el juego unos milisegundos en el pasado, con un retraso que varía tanto entre los jugadores como a lo largo del tiempo. En general, esto rara vez es un gran problema. Si realmente quieres almacenar en el búfer algunos estados pasados ​​en el servidor, puedes interpolar entre ellos y enviar diferentes datos antiguos a diferentes personas en un intento de sincronizar lo que ven, pero combinado con la simulación del lado del cliente y la inestabilidad en los tiempos de transmisión. Todavía veré algunas diferencias entre las máquinas.

2 - la forma típica es ejecutar la simulación en el servidor y enviar actualizaciones de estado regulares (pequeñas) a los clientes. Los clientes normalmente ejecutan sus propias simulaciones y tienen una forma de combinar su propio estado predicho / interpolado y el estado autoritario que el servidor les está enviando. Todas las decisiones que no sean de entrada del usuario deben hacerse en el lado del servidor. En definitiva, la forma en que combinas estos es solo una compensación entre una apariencia suave y un estado preciso, por lo que es una decisión cosmética que tendrás que tomar.

3 - su cliente normalmente debe traducir una pulsación de tecla a una acción lógica. Su servidor no se preocupa por las claves. Envíe esa acción lógica al servidor y puede transmitirla a otros clientes si la necesitan. Aunque en general no necesitarás hacer nada aquí, cualquier cambio relevante causado por la acción generalmente cambiará el estado del juego y, por lo tanto, se enviará en la transmisión normal de ese estado.

Answer 3

La mejor manera es realizar un seguimiento de todos los objetos en un solo lugar, es decir, el servidor. Todos verán la información de los servidores un tiempo de viaje más tarde de lo que realmente sucede y los comandos de las personas tomarán un viaje para registrarse en el servidor. Realmente no hay forma de evitar esto. Para algunas aplicaciones, puede ser práctico simular su propio movimiento de inmediato sin esperar una respuesta del servidor, pero esto indudablemente dará lugar a una pesadilla con la programación de temporización y las personas típicamente se verán "retrasadas". La detección de colisiones es casi imposible.

El efecto neto de esto es que habrá una lentitud desde que ingrese sus comandos hasta que los vea realmente sucediendo, pero ojalá las personas aprendan a lidiar con esto y traten de ingresar sus comandos un poco antes para compensar. Con conexiones lentas, los juegos rápidos en tiempo real son simplemente imposibles.

Answer 4

No abordaré sus puntos directamente porque las otras respuestas lo hacen tan bien. Pero, sugiero buscar en HTML5, WebSockets y Comet, que prometen mejorar significativamente el rendimiento en tiempo real. Estas tecnologías le permiten tener solicitudes HTTP de larga ejecución, lo que permite que el servidor envíe datos al cliente en lugar de que el cliente interrogue al servidor. Esto puede acelerar sustancialmente las cosas.

Aquí hay algunos recursos que deberían ser útiles:

• Entrada de Wikipedia WebSockets
• Wikipedia Comet entry
• Usando Node.js con Comet
• Integración de Node.js y más información
• Buena presentación de diapositivas en Node.js, Comet y WebSockets
• Socket.IO (servidor y cliente de WebSockets de Node.js con errores)

Answer 5

Respondí otra pregunta similar a esta en relación con los problemas de latencia que valdrá la pena leer, sincronizar con el cliente más lento podría no ser la mejor solución según el juego.

Otra pregunta de : sincronización de movimiento de juego multijugador

Answer 6

Si está buscando algún código de muestra para aprender, hay un juego de multijugador en línea de Pong hecho en ActionScript , con física del lado del servidor interpolada por los clientes.

Ese ejemplo de Pong se basa en la plataforma de la Unión , que está disponible de forma gratuita para hasta 1000 conexiones simultáneas de clientes.

Union tiene un marco de cliente de JavaScript, OrbiterMicro (JavaScript Client) .

Y también puede escribir su lógica del lado del servidor en JavaScript; consulte Creación de módulos de sala con JavaScript .

(Divulgación completa: soy el cofundador de Union).

Answer 7

Un enfoque típico no es tratar de forzar a todos los clientes a ejecutar en el mismo framerate bloqueado en el servidor ... simplemente se pone feo. En su lugar, envíe actualizaciones frecuentes para que los clientes puedan actualizar cada vez que reciban una nueva actualización.

Normalmente, un cliente predecirá cómo van las cosas durante períodos cortos, luego se corregirá con una actualización del servidor. Puede aplicar correcciones de tiempo también. Por ejemplo, si el servidor le dice "el jugador 2 está en P viajando a velocidad V", puede intentar conocer la antigüedad del mensaje basándose en un ping reciente y corregir la posición de P a P + x*D .