2011-11-30 19 views
12

Intento encontrar el mejor método para hacer esto, considerando un juego de cross-plateform de giro por lado en el móvil (ancho de banda 3G) con proyectiles y bloques que caen.¿Cómo sincronizar la física en un juego multijugador?

Me pregunto si un dispositivo (el jugador actual turn = role del servidor) puede ejecutar la física y enviar algunos datos "key frames" (posición, orientación de bloques) al otro dispositivo, que simplemente interpola desde el estado actual a los "fotogramas clave" recibidos. Con este método, tengo bastante miedo de la gran cantidad de datos para garantizar la misma imagen en el dispositivo del otro jugador.

Otro método debe ser enviar los datos de física (fuerza, aceleración ...) y ejecutar la física en el otro dispositivo también, pero me temo que nunca tendrá el mismo resultado.

+0

¿Los objetos no tendrían exactamente el mismo resultado en ambos dispositivos si los objetos tienen la misma posición inicial y se aplicaron los mismos datos de la física? – Kjetil

+0

@Kjetil solo si tiene un tiempo fijo marcado. Por lo general, este no será el caso si actualiza la física en cada cuadro de gráficos. –

+0

Derecha Rob. No estoy seguro, pero los problemas deberían venir considerando la multiplataforma (diferentes arquitecturas) y el cálculo de punto flotante, ¿no? –

Respuesta

9

Mi implementación actual funciona así:

  1. Server administra simulación física
  2. En cualquier colisión importante de cualquier objeto, posición, rotación, y la velocidad/aceleración/fuerzas absolutas del objeto se envían a cada cliente .
  3. El cliente establece cada objeto en la posición junto con su velocidad y aplica las fuerzas necesarias.
  4. El cliente calcula la latencia y avanza el sistema de física para acomodar el tiempo de retraso en esa cantidad.

Esto, para mí, funciona bastante bien. Tengo el sistema de física corriendo por docenas de subsistemas (mapas).

Algunas cosas importantes acerca de mi aplicación:

ignoran completamente cualquier objeto que no está marcado como "necesario". Por ejemplo, partículas de polvo y suciedad que responden al movimiento del jugador o al césped y al agua, ya que responde al movimiento del jugador. Básicamente cosas no esenciales.

Todo esto se envía a través de UDP por cierto. Esto sería horrendo en TCP.

6

Deseará enviar posiciones y rotaciones absolutas.

Tienes razón, si envías solo fuerzas, no funcionará. Es posible hacer que esto funcione, pero es mucho más difícil que simplemente enviar posiciones. Necesita ambos dispositivos para hacer sus cálculos de la misma manera, por lo que antes de cada cuadro, debe esperar la entrada del otro dispositivo, debe usar el mismo paso de tiempo, los scripts deben ejecutarse en el mismo orden o ser conmutativos. , y solo puede usar instrucciones de CPU garantizadas para dar el mismo resultado en ambas máquinas.

que la última es una que lo hace particularmente problemático, porque significa que no puede usar números de coma flotante (flotantes/sencillos o dobles). tiene que usar enteros, o rolar su propio formato numérico, por lo que no puede aprovechar muchas herramientas existentes.

Muchos juegos usan un modelo cliente-servidor con predicción del lado del cliente. si su juego se basa en turnos, es posible que pueda salirse con la suya sin utilizar la predicción del lado del cliente. en su lugar, puede hacer que el cliente se quede rezagado por cierto tiempo, de modo que puede estar bastante seguro de que la entrada del servidor ya estará allí cuando vaya a renderizar. la predicción del lado del cliente solo es importante si el cliente puede hacer cambios que le importan al servidor (como moverse).

+0

Al esperar la entrada de cada fotograma, supongo que se refiere a cada fotograma de la física. – RobotRock

+0

Me refiero a cada cuadro de entrada, que podría ser de 1 a 1 con marcos de física, o no. Sería más fácil tener marcos de entrada y marcos de física de 1 a 1, pero podrías actualizar la física dos veces cada vez que muestreases la entrada, si así lo deseas. – notallama

Cuestiones relacionadas