¿Cómo predecir el movimiento correctamente cuando un jugador es invisible?

Tengo un juego multijugador y estoy haciendo predicciones del lado del cliente, pero algunos jugadores pueden beber una poción y volverse invisibles ...

El problema es que cuando se vuelven invisibles no comparto nada que el cliente pueda usar para saber que está allí, por lo que cuando un jugador intenta entrar en una casilla ocupada por un jugador invisible, predice que tiene éxito y luego obtiene un Corrección de posición fea enviada por el servidor.

Una solución sería compartir algo para que el cliente pueda decirlo, pero luego los piratas informáticos podrían usarlo para descubrir dónde están los jugadores invisibles, haciendo trampa.

Por cierto, ya resolví la predicción de movimiento regular, funciona perfectamente.

multiplayer client-server

— affiszervmention
fuente

Simplemente envíe la información sobre todos los jugadores. Los tramposos van a hacer trampa. No perjudique la experiencia de los jugadores honestos y piense en crear un sistema de señalización para los tramposos.

— user1306322

@ user1306322 Al facilitar a los tramposos, también paralizarás a los jugadores honestos. Un sistema de marcado es una buena idea, pero si la invisibilidad es una gran parte del juego, algo preventivo podría ser necesario.

— ThatOneGuy

@ user1895420 suele ser lo suficientemente bueno como para no enviar esas cosas en texto sin formato, de modo que ningún jugador promedio pueda obtener fácilmente esos datos. Si solo una persona experta en tecnología puede hacerlo, entonces es tan buena medida preventiva como cualquier otra.

— user1306322

O, tal vez, es una mejor idea cambiar un poco la mecánica de invisibilidad para que no funcione muy cerca, por lo que incluso aquellos que pueden hacer trampa en los datos del juego realmente no pueden obtener ninguna ventaja.

— user1306322

¿Qué tal simplemente enviar la posición del jugador invisible (con una bandera para mantenerlo invisible) solo cuando un jugador visible está cerca? Eso debería darte un par de cuadros para evitar el problema del exceso de movimiento, mientras que no debería dar a los tramposos suficiente tiempo para reaccionar. Para dos jugadores invisibles, simplemente ignoraría la colisión. Si tiene un servidor central que tiene todas las posiciones de los jugadores, también puede hacer que coordine cuándo difundir la posición y cuándo no.

— jdm

Respuestas:

Esto podría considerarse un problema de animación. Si una corrección de posición regresa del servidor debido a un intento de moverse a un objeto invisible, envíe no solo la corrección sino también una bandera que indique por qué la corrección fue necesaria. En lugar de que un jugador salte hacia atrás, puede hacer una especie de "woah" de animación de retroceso, haciendo que parezca que se encontró con algo.

En los juegos que utilizan este enfoque, no es raro eliminar la invisibilidad (al menos momentáneamente) de todo lo que se encontró. Entre otras cosas, esto incentiva a los jugadores invisibles a evitar multitudes o acercarse demasiado a otros personajes, lo que reduce la frecuencia con la que se produce una colisión con un jugador invisible. Por lo tanto, incluso si su animación para este tipo de colisión es débil (o inexistente), está oculta de alguna manera por el personaje invisible que aparece en la visibilidad y claramente telegrafía a todos lo que acaba de suceder.

La necesidad de animación podría eliminarse al no permitir que la invisibilidad funcione a corta distancia. Esto da aún más incentivos a los jugadores invisibles para evitar acercarse a otros personajes. Este es un enfoque común para los juegos basados en el sigilo y la IA (reemplace "invisible" con "no visible para el objetivo") y se puede ver en juegos PvP como World of Tanks. No hay necesidad de preocuparse por la respuesta de colisión con personajes invisibles si nada invisible está lo suficientemente cerca como para chocar (dentro de los límites de latencia).

La solución de Dracor para ignorar las colisiones con objetos invisibles también es buena. Esto requiere de nuevo algunas animaciones (para el cliente invisible de los jugadores) para que los objetos no se limiten a recortar el avatar del jugador en su pantalla. De lo contrario, puede hacer que los objetos visibles empujen siempre a los invisibles para que el jugador invisible se retire automáticamente del servidor si alguien colisiona con él.

Las colisiones invisibles invisibles son un poco más complicadas. Puede ser ventajoso simplemente deshabilitar las colisiones en ellos ya que nadie puede ver si dos objetos invisibles se están uniendo (suponiendo que "invisible" queremos decir que ambos objetos no son visibles para el mismo cliente). Si uno de los objetos se vuelve visible, automáticamente vuelve a la respuesta de colisión visible-invisible (empuje el objeto invisible).

Todo esto se vuelve más complicado si la invisibilidad tiene conjuntos complicados de quién puede ver a quién. La primera o segunda solución anterior es probablemente mejor aquí si la necesita. No todos los problemas como este necesitan una solución técnica; muchos solo necesitan soluciones de diseño (p. ej., no permitan esta característica a sus diseñadores).

— Sean Middleditch
fuente

El juego Team Fortress 2 usa ese primer enfoque ... Si un espía invisible toca a otro jugador, el otro jugador puede ver al espía (o si desde atrás, al menos siente algún obstáculo).

— Xantix

Realmente solo veo dos opciones aquí si no quieres decirle al cliente dónde está el jugador invisible: 1) Ignoras la colisión de unidades para jugadores invisibles: una solución simple, y los jugadores no podrían encontrar a los jugadores invisibles por pruebas de colisión tampoco. 2) Después de decidir la ruta prevista, envía al servidor la ruta prevista y corrige la ruta en el lado del servidor, luego envía la nueva ruta de regreso.

— Daniel Rusznyak
fuente

El problema de ignorar la colisión para jugadores invisibles es si un jugador invisible deja de ser invisible justo cuando está colisionando con otra persona. Además, no se siente bien. En mi juego, realmente no tengo caminos ni pistas, los jugadores solo pueden moverse en las 4 direcciones, un paso a la vez

— affiszervmention

Entonces lo que queda es enviar el movimiento predicho (ya sea un solo vector o una matriz de vectores) y hacer una verificación del lado del servidor. O simplemente animar la corrección, como se dice a continuación.

— Daniel Rusznyak

Si tiene un mapa basado en la cuadrícula y está revisando cada cuadro uno por uno de todos modos, también puede intentar codificar la ubicación de los caracteres invisibles en el lado del servidor con una codificación unidireccional, como SHA-1 o SHA-2 , luego verifique su propia ruta codificando las coordenadas marcadas con el mismo algoritmo. No puedo decir que sea eficaz para el rendimiento, pero si realmente quieres hacerlo del lado del cliente, esta solución puede funcionar tan bien con un número limitado de posiciones, y el pirateo puede ser realmente problemático debido a la gran cantidad de puntos de cuadrícula para codificar y coincidir con los datos en la memoria.

— Daniel Rusznyak

Puedo ver que funciona. Mi mapa más pequeño tiene 1500 posiciones diferentes. ¿Debo usar HMAC con la clave cambiando cada pocos segundos para evitar que el atacante precalcule todas las posiciones?

— affiszervmention

No, cualquier esquema que se te ocurra no sería "seguro" contra los piratas informáticos. Si el cliente puede determinar si el jugador chocará contra una posición determinada, entonces alguien puede hackear tu juego. HMAC con una tecla giratoria no impedirá que el cliente realice 1500 HMAC por segundo. No , no intente hacerlo usted mismo la criptografía. Si desea lograr el objetivo original, solo envíe la posición invisible del jugador al cliente si está dentro de 1 o 2 casillas del jugador. Entonces solo puedes hackear para saber si alguien está justo a tu lado (lo cual no es útil porque solo puedes moverte para verificar esto).

A menos que esté malinterpretando algo, la solución es simple. No envíe información al cliente sobre todos los jugadores invisibles, solo aquellos que estén dentro del alcance que puedan estar sujetos a colisión dentro de los límites de movimiento durante el intervalo que se predice. En otras palabras, si el cliente solo tiene que predecir 200 ms en el futuro, solo envíe información sobre jugadores invisibles dentro de las max_player_velocity units/sec * 1/5 secunidades de distancia.

— R ..
fuente

Supongo que eso podría funcionar, pero mi juego está basado en mosaicos (olvidé decirlo).

— affiszervmention

Así que solo revela jugadores invisibles en fichas adyacentes, o a 2 pasos de distancia, o lo que sea.

— R ..

entonces no está seguro de que colisionarían, y los jugadores invisibles tendrían que mantenerse alejados de cualquier persona que

— piratee