Sincronización multijugador y pathfinding

8

Tengo una interfaz de tipo apuntar y hacer clic en un cliente, que ejecuta una A * en el servidor, para buscar rutas.

El juego se controla como un RTS, pero el mundo es persistente, por lo que los jugadores deberían poder unirse / salir en cualquier momento, y solo habrá aproximadamente 30 unidades como máximo en la pantalla.

¿Cuál es la mejor manera de sincronizar los movimientos del jugador entre el servidor y el cliente, una vez que he calculado las rutas?

¿El servidor necesita sincronizar a los clientes en cada paso / cuadro de animación? ¿o puede simplemente decirle al cliente "ir a la posición X, Y" para cada nodo en el camino y cada jugador en movimiento? ¿O es mejor simplemente ejecutar los temporizadores de animación tanto en el cliente como en el servidor, y hacer que se sincronice implícitamente de esa manera?

¿Cómo sería el típico intercambio de datos para el movimiento basado en la ruta?

EDITAR:

Algunos de ustedes han estado sugiriendo bloqueo, porque dije "RTS", pero el juego no es un RTS, solo tiene el mismo tipo de interfaz. La gran diferencia es que necesito poder hacer que los jugadores se unan y abandonen el juego en cualquier momento . Perdón por no ser más específico.

cabeza de nube
fuente

Respuestas:

2

Una alternativa es hacer pathfinding en el cliente que posee la unidad. Esto tiene la ventaja de extender el trabajo de manera más uniforme. Una desventaja de hacer todo el pathfinding en el servidor es que el servidor tiene que hacerlo todo; Una desventaja de enviar solo comandos 'mover a X, Y' a los clientes es que cada cliente tiene que encontrar cada ruta. En cambio, cada 'tic' en el ciclo de paso de bloqueo, cada cliente le dice al servidor, literalmente, el siguiente paso de su unidad. El servidor se asegura de que la unidad pueda moverse allí, y la mueve. Dado que el cliente no tiene toda la información (en particular, lo que están haciendo las unidades del otro cliente), un comando de movimiento no válido no se trata como un error. Esto está dejando algo de ancho de banda para ganar más tiempo para calcular rutas.

Reemplace el servidor con el igual; Este método también funciona para juegos de igual a igual, siempre y cuando se asegure de que el orden en que se consideran los movimientos de las unidades sea el mismo en todas las máquinas.

Blecki
fuente
1

Los juegos RTS generalmente tienen sincronización de bloqueo (la sincronización ocurre en cada cuadro). Decirle cualquier ruta al cliente permitiría a los clientes pirateados abusar de la información adicional.

Cloudanger
fuente
1

Ninguno. Lo único que debes enviar son los comandos. Ejemplo: estas 20 unidades deben moverse a (X, Y) y luego dejar que cada jugador descubra cómo llegar allí. La parte difícil es asegurarse de que todos hagan exactamente lo mismo. Para lograr esto, se utiliza un modelo de bloqueo, los enlaces a continuación deben explicarlo en detalle. Además, solo debes sincronizar las piezas importantes. Cualquier cosa que no cambie la jugabilidad no debería sincronizarse. Las animaciones en los juegos RTS generalmente son solo para el lado visual.

Otra cosa, los juegos RTS generalmente no son cliente-servidor, sino P2P. De esa forma, uno de los jugadores no puede hacer trampa porque cuando se detecta cualquier inconsistencia, simplemente se desconecta.

Aquí hay algo para ayudarlo a comenzar: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://altdevblogaday.com/2011/07/09/synchronous-rts-engines-and- a-tale-of-desyncs / http://altdevblogaday.com/2011/07/24/synchronous-rts-engines-2-sync-harder/

Peter Ølsted
fuente
El problema es que necesito jugadores para poder unirme y salir en cualquier momento. El juego no es un RTS, solo tiene una interfaz similar.
cloudhead
Si tiene más que decir, 50 objetos totalmente dinámicos en un momento dado, es posible que deba analizar la mecánica de RTS. ¿Tu juego es algo como CIV o LOL?
Peter Ølsted
Es más como Diablo, Dungeon Siege o HoN, pero con apuntar y hacer clic. No debería haber más de ~ 20 unidades en pantalla como máximo.
cloudhead
1

Una vez que se calcula la ruta, el servidor solo usa esa ruta para controlar el personaje. La presencia de una ruta no hace ninguna diferencia para este problema: todavía se envían los mismos datos, ya sean actualizaciones de posición regulares o lo que sea. Por lo general, está bien enviar posiciones regulares (interpoladas en el cliente para suavizarlas) y un mensaje separado cuando la unidad se detiene.

Kylotan
fuente
Ok, a eso es a lo que me dirijo.
cloudhead
1

En mi juego (un juego de tipo RPG multijugador) envío partes del camino al cliente (para NPC cercano), es decir. las 3 siguientes posiciones y el momento en que el NPC debería estar allí. Para los jugadores, solo envío la última posición válida + su marca de tiempo para que en el cliente pueda hacer un cálculo muerto (o algo más elaborado si lo desea).

Esto funciona completamente bien principalmente porque no hay colisiones entre jugadores / NPC (con un retraso bajo no se nota realmente nada, con un retraso de más de 250 ms notará la diferencia si puede ver las dos pantallas (de dos jugadores ) al mismo tiempo, pero todavía no es realmente notable en 'una pantalla').

Entonces diría: vaya con la autoría del servidor (validación de posiciones + marcas de tiempo de los jugadores y también para la IA al principio, puede hacer un sistema más elaborado para el NPC más adelante sin mayores problemas) + predicción del cliente.

PD. Utilizo una precisión de milisegundos que funciona perfectamente bien, excepto que un int firmado solo se mantiene durante unas 3 semanas antes de tener que reiniciar el servidor.

También es posible que desee verificar la predicción del tiempo (es decir, tratar de sincronizarse lo más posible con el servidor).

Valmond
fuente