Juego multijugador con backend y frontend JavaScript. ¿Cuáles son las mejores prácticas?

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 cerca de 20 personas máximo en cada habitación ', así que tengo algunas ideas:

1. ¿Cómo compensar el retardo entre todos los usuarios, de modo que todo el mundo ve la misma cosa 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 tener 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. Debería recibir 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 estado de vez en cuando para sincronizarlos?

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

Por favor, publique sus pensamientos o enlaces a la documentación o artículos sobre juegos multijugador.

---

EDIT: Estos son útiles:

• Gaffer on Games - Muy buenos artículos de Glenn Fiedler en redes juego de varios jugadores y la física
• The Quake3 Networking Model

Answer 1

1. Éste 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 corta de la interfaz al servidor, modificaría el estado del juego y publicaría los eventos de modificación del estado del juego 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

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.

Éstos son algunos de los recursos que deben ser útiles:

• Wikipedia WebSockets entry
• Wikipedia Comet entry
• Using Node.js with Comet
• Node.js integration y more information
• Good slideshow on Node.js, Comet, and WebSockets
• Socket.IO (Node.js WebSockets server and client with fallbacks)

Answer 4

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, y luego se corregirá con una actualización del servidor. Puede aplicar correcciones de tiempo también. Por ejemplo, si el servidor le dice que "el jugador 2 está en P viajando a velocidad V", puede intentar conocer la antigüedad de ese mensaje en función de un ping reciente y corregir la posición desde P hasta P + x*D.

Answer 5

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 e intenten ingresar sus comandos un poco antes para compensar. Con conexiones lentas, los juegos rápidos en tiempo real son simplemente imposibles.

Answer 6

Si usted está buscando un código de ejemplo para aprender de, no es un juego multijugador en línea de Pongdone in ActionScript, con la física del lado del servidor interpolados por los clientes.

Ese ejemplo de Pong se basa en el Union platform, que está disponible de forma gratuita para hasta 1000 conexiones de cliente simultáneas.

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

Y usted puede escribir su lógica del lado del servidor en JavaScript también, vea Creating Room Modules with JavaScript.

(La revelación completa:. Soy el co-fundador de la Unión)

Answer 7

me contestó otra pregunta que era similar a esto en relación con los problemas de latencia que será una lectura vale la pena, la sincronización con el cliente más lento podría no ser la mejor solución según el juego.

Otra pregunta StackOverflow: Multiplayer game movement synchronization