¿Consejos para la comunicación entre el juego de navegador JS y el servidor node.js? [cerrado]

Estoy jugando con un simple juego de cueva basado en Canvas y me gustaría convertirlo en multijugador eventualmente. El plan es usar Node.js en el lado del servidor.

Los datos enviados consistirían en la posición de cada jugador, dirección, velocidad y demás. Los movimientos del jugador son simples físicas de fuerza, por lo que debería poder extrapolar los movimientos antes de la próxima actualización del servidor.

¿Algún consejo o mejores prácticas en el lado de las comunicaciones? Supongo que los sockets web son el camino a seguir. ¿Debo enviar información en cada pasada del ciclo del juego o con intervalos específicos? Además, no me importa si no funciona con navegadores antiguos.

Recientemente hice un crossover de asteroides / geometry wars con Node.js / JavaScript:
http://github.com/BonsaiDen/NodeGame-Shooter

Tiene un servidor gordo que procesa el juego y clientes ligeros que son básicamente solo vistas. El cliente hace algunas interpolaciones y cosas para que se vea suave.

Es posible que desee ver estos dos archivos, que contienen la lógica de red subyacente, así como los modelos de actor y cliente:
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/client/nodegame.client. js
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/server/nodegame.js

Todo el juego se basa en actores que manejan sus "eventos de actualización" (las cosas que se envían a los clientes) solos, en su mayor parte. También es posible ocultar actores de un cliente específico para implementar, por ejemplo, invisibilidad.

También se pueden grabar juegos y simplemente enviar los mensajes al cliente para reproducirlos.

En lo que respecta a la tecnología:
WebSockets son el camino a seguir aquí. También hice una codificación binaria personalizada para JS que, si bien renuncio a cosas como más de 2 decimales en flotantes, es aproximadamente un 50% más pequeña que JSON (y es 2 veces más rápido en V8 que la codificación JSON nativa )

Sugeriría mantener las cosas separadas.

En Stendhal, que es un MORPG 2D escrito en Java, hicimos lo siguiente y funciona bastante bien:

• El cliente usa un bucle rápido para dibujar. Hace una animación suave y algunas predicciones para minimizar el retraso.
• El servidor usa un bucle para procesar toda la lógica del juego. En nuestro caso, puede ser mucho más lento que el bucle de dibujo. Mientras los clientes hacen algunas predicciones, el servidor siempre gana.

La comunicación entre el cliente y el servidor se realiza mediante acciones y percepciones:

• Las acciones realizadas por los usuarios como "subir" se envían al servidor cuando ocurren. El servidor los pone en cola y los procesa en su propio bucle.
• Las percepciones se envían desde el servidor al cliente para actualizar su visión del mundo.

Hicimos algunos "trucos" para obtener un rendimiento adicional:

• Tenemos dos tipos de mensajes de percepción: uno completo utilizado para iniciar sesión y los jugadores que se unen a una zona. Y actualizaciones incrementales utilizadas después de eso. Esto ahorra mucho ancho de banda de red.
• Dividimos los mensajes de percepción en una parte pública y una privada: todos los jugadores en la misma zona comparten la misma parte pública, por lo que ahorramos tiempo de procesamiento porque la serialización resultó ser un cuello de botella en Java (no JavaScript).

Use socket.io , es una práctica biblioteca de abstracción de WebSockets que proporciona fallos para navegadores que no la admiten.

Además, si está buscando un modelo en línea como ese, recomendaría mover el procesamiento del juego al servidor. De esa manera, solo necesita comunicar los cambios gráficos y la entrada del mouse / teclado. También ayuda bastante para evitar las trampas.