2012-01-20 30 views
12

Quiero hacer un juego de pong de 2 jugadores que use websockets y el servidor node.js. socket.io se usa tanto en el cliente como en el servidor. Hasta ahora, mi única experiencia es crear una aplicación de chat.Cómo usar websockets para juegos en tiempo real

Este es mi primer intento en un juego multijugador, así que no estoy tan familiarizado con los juegos en red. ¿Debe el servidor realizar un seguimiento de:

  1. ¿En cada posición está la pelota y con qué frecuencia o cuándo?
  2. movimiento del reproductor, el jugador se mueve hacia la izquierda o hacia la derecha, ¿qué sucede si presiono y sostengo durante un tiempo, cómo puedo manejar esto? ¿Debo enviar como pressHoldStartPosition y pressHoldStopPosition? Supongo que esto es fácil si solo dejo presionar pero no presionar.

Mis pensamientos:

  1. Cuando la pelota golpea un jugador, el cliente calcula la velocidad, la posición inicial y final y el otro cliente debe realizar la animación correcta de eso.
  2. No hay idea.
+1

Definitivamente, debería echarle un vistazo al blog @RobHawkes: http://rawkes.com/ Ha desarrollado, y continúa compilando, un juego multijugador en HTML5 llamado Rawkets http://rawkets.com/. Estoy seguro de que habrá compartido un montón de información sobre temas que son muy relevantes para lo que está buscando y cosas adicionales que encontrará. – leggetter

Respuesta

13
  1. Los clientes calculan nada, a menos que lo deseen para predecir el siguiente paso del juego * (servidor del remitente).Todo el juego se ejecuta en el servidor, que es una única y confiable fuente de datos y cálculos. En los juegos tipo Pong, donde hay menos de 10 objetos, puede enviar datos con bastante frecuencia (un intervalo de 50 ms). Para una pelota enviaría [x, y, velocidad, o ángulo], para paletas [x, y]. Luego interpola (anima en el tiempo - 50ms) entre el antiguo (x, y en el cliente) y el nuevo (x, y que acabas de obtener del servidor).

  2. No envíe miliones de - jugador presionado - en lugar de enviar un paquete cada período de tiempo (100ms?) Que contenga información como "jugador presiona arriba" durante 100ms, o "jugador establece posición" a (32 , 100) luego verifica el lado del servidor si este movimiento es posible y lo acepta o rechaza.

Tal vez este tema le ayudará con su aventura:

Multiplayer JavaScript game built with Node.JS - Separating players

[* 1] preditction es un mecanismo de compensación de retardo que se puede aplicar después. De forma simplificada, significa que el servidor y el cliente comparten parte del código lógico del juego y, cuando el cliente no tiene datos actuales del servidor, intenta simular lo que está sucediendo en el juego real.

2

Va a encontrar libros, sobre libros, sobre redes de juego.

En una breve descripción, esto es lo que encuentro una implementación interesante: El servidor y el cliente calculan la física del juego. El servidor será un maestro y tendrá un estado correcto de todas las entidades, mientras que el cliente intentará "predecir" el estado de las entidades y mantener una animación fluida. El cliente se actualizará periódicamente el estado correcto de las entidades del servidor. En algunos juegos, es posible que vea que las entidades se teletransportan repentinamente, y esto se debe a que la posición del cliente prevista no coincide con la posición real del servidor.

Un estado de entidad, como la bola o los jugadores, generalmente contiene información tal como la posición, velocidad, estado de los botones (tecla abajo/tecla arriba).

Además de eso, está dejando volar su imaginación y probar la mejor solución y ver qué funciona. Hay mucho que tomar en consideración, como la latencia del jugador y el ancho de banda.

2

Hay un sitio StackExchange dedicada al desarrollo de juegos: https://gamedev.stackexchange.com/

La mejor práctica es enviar sólo las actualizaciones que los clientes necesitan saber acerca. Además, generalmente envía el resultado de las acciones del usuario y no las acciones en sí. No es necesario enviar las cosas que se pueden calcular (física), excepto los puntos de sincronización periódicos para tener en cuenta los errores de coma flotante que acumulan errores a lo largo del tiempo y se sincronizan con las acciones de los usuarios remotos. Esto también hace que el juego parezca más interactivo y cubre algunos de los tartamudeos que resultan de la latencia y la inestabilidad de la red.

La desventaja principal de este modelo es que si tiene una alta latencia de red o caídas de paquetes, obtendrá el efecto de línea de tiempo divergente cuando el cálculo de la física continúe y de repente reciba una actualización del usuario remoto que indique que hicieron algo para Efectuar la física con la que aún no habíamos atrapado. Pero este es un problema estándar en la mayoría de los juegos en red y las alternativas son peores para la mayoría de los tipos de juegos en tiempo real.

Cuestiones relacionadas