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
fuente
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).
fuente
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.
fuente
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.fuente