19

He estado pensando en implementar el sigilo en un juego multijugador. Es un juego de estilo MOBA, así que piensa en League of Legends (LoL) y Heroes of the Storm (HotS). Varios clientes se conectan a un solo servidor, que transmite el estado del juego a todos los clientes. Los clientes envían sus datos de entrada al servidor, que pueden rechazarlos cuando encuentran comandos no válidos, lo que hace que la trampa sea imposible (bueno, en teoría).

Ahora, menciono estos juegos a propósito porque ambos implementaron sigilo de manera diferente. LoL tiene sigilo con dos estados posibles: eres completamente visible o completamente invisible. HotS, por otro lado, implementa el sigilo de tal manera que se puede ver por un brillo en el aire:

Creo que esta es una mecánica ordenada, ya que promueve / recompensa prestando atención a su entorno. Sin embargo, al ser un juego multijugador, me di cuenta de que podría resultar fácilmente explotable.

Cuando implementa el sigilo en la forma 'LoL', simplemente puede dejar de enviar coordenadas de jugador a los otros clientes. Cuando el personaje del jugador rompe el sigilo, el servidor puede transmitir la ubicación nuevamente. Sin embargo, con el modelo HotS, se puede ver un brillo en el aire donde se mueve el personaje. Esto significa que el servidor debe enviar la ubicación del jugador a los otros clientes. Lo que significa que los jugadores que cambian la textura o el modelo o incluso el código del juego en sí mismo podrían hacer que la mecánica de la capa sea inútil. Aquí hay un hilo en los foros de HotS al respecto.

Mi pregunta es si hay alguna forma de implementar el encubrimiento (con un 'brillo', al estilo HotS), sin tener el problema de que los jugadores astutos pueden modificar el juego (datos) y 'vencer al sistema'. ¿Es esto posible, y si no, cómo otros juegos multijugador con esta mecánica lidian con esto? ¿Solo el estilo de invisibilidad LoL es incontrolable?

Pensé en hacer que el servidor enviara ubicaciones falsas de 'capa' de vez en cuando, pero esto también perjudica a los jugadores justos que solo están prestando atención, por lo que no funcionará.

multiplayer game-mechanics anti-cheat

— Underflow
fuente

Relacionado es el enlace , pero no estoy preguntando sobre tropezar con otros (que pueden ser manejados por el servidor) sino mostrar unidades ocultas.

— Underflow

Esta es una mala sugerencia, pero podría hacer todo el procesamiento gráfico en el servidor y luego transmitir la pantalla de cada jugador a sus clientes. Solo envían entradas, solo envías salidas. El cliente es un shell delgado que simplemente muestra el video y reproduce el audio.

— user137

Philipp tuvo una muy buena idea allí. Quiero agregar que aún debe ser consciente de los cuadros delimitadores y su intersección con disparos de habilidades, etc. Si envía cuadros delimitadores, un codificador inteligente puede aplicar ingeniería inversa a qué personaje es invisible (si hay héroes diferentes). Si tienes algún efecto que se dispare al golpear, entonces tendrás que enviar algo como el cuadro o al menos la posición y la escala del efecto. Tenga en cuenta que todo lo más abstracto es más

— Greaka

En realidad, no puede implementar el encubrimiento de estilo LoL al dejar de enviar coordenadas de jugador. Incluso si los personajes no se dibujan, aún necesitan poder interactuar con el mapa (y otros jugadores) de otras maneras. Pero la implementación de sigilo "detectable" (huellas, brillos, etc.) elimina gran parte del incentivo para pasar por el problema de modificar el juego de todos modos: aprende a detectar personajes encubiertos y seguir adelante.

— El Spooniest

2

@TheSpooniest: ¿podrías explicar a qué te refieres? En realidad, no puedes implementar el encubrimiento al estilo LoL al dejar de enviar las coordenadas del jugador ? Si el jugador A es invisible y el servidor ya no envía las coordenadas a los jugadores B y C, el servidor aún puede manejar, por ejemplo, la colisión entre los jugadores A y B al negarse a mover el personaje de B sobre A (como si caminaran en una pared). Si A (aún invisible) dispara una habilidad a B, el servidor puede simplemente enviar "habilidad disparada desde la posición x, y en la dirección d de A" a B y C.

— Flujo

20

No puedes implementar un efecto de brillo sin hacer que sea fácil de explotar ... pero ¿qué pasa si usas un medio indirecto de mostrar que alguien está cerca, un medio que también se aplica a los jugadores visibles?

Por ejemplo, ¿qué sucede si los jugadores dejan huellas y se envían mensajes de "huella creada" desde el servidor independientemente de la ubicación del jugador? Cada jugador deja huellas, por lo que no puede hacer que el modelo de huella sea más visible sin cubrir la arena en ellas y hacer que cada impresión individual sea menos notable, pero si un jugador ve aparecer una huella sin un personaje visible, saben que hay alguien allí.

También puede hacer cosas como tener pequeños guijarros que se golpean, susurrar el césped cuando alguien lo atraviesa o las ondas que aparecen cuando alguien se mueve a través del agua. Si los 'signos' solo se aplican a ciertos lugares o materiales, esto podría agregar una estrategia adicional que obligue a los personajes invisibles a moverse con cuidado y evitar cosas que delaten sus posiciones.

— IndigoFenix
fuente

without making it easy to exploit-> Esto se aplica a todas las mecánicas de juego, no solo a esta en particular.

— S. Tarık Çetin

12

Con respecto al último párrafo: tenga en cuenta que cuando un jugador invisible es lo único que hace que sucedan estas cosas, entonces está proporcionando información que es útil para los piratas informáticos. Pero también puede activar cada uno de ellos de vez en cuando a través de eventos aleatorios u otras acciones del jugador. Eso generaría un ruido que distrae al pirateo y tiene el agradable efecto secundario de hacer que el entorno parezca mucho más vivo y dinámico.

— Philipp

2

Esta es una idea muy interesante, ¡gracias! En el caso de las "huellas", esto podría incluso recompensar a los jugadores sigilosos a "caminar dentro" de los pasos (antiguos) de su objetivo, haciendo que escabullirse hacia otros sea más realista (es decir, venir desde atrás). Incluso si alguien hace que las texturas de los pasos (o lo que sea que tengas) sean más obvias, pisarlas (quizás) solo refrescaría la duración de la pantalla.

— Underflow

3

Por supuesto, en este caso, se podría hacer un truco del lado del cliente para mostrar qué pistas son nuevas.

— Muhd

3

Un pirateo del lado del cliente podría resaltar las huellas que se crean en regiones que no corresponden a la ubicación de un jugador.

— Edward Coffey

31

Cuando miras las innumerables otras preguntas sobre cómo evitar las trampas en los juegos multijugador que se encuentran en este sitio, verás fácilmente que realmente no hay una medida técnica para evitar las trampas del lado del cliente.

Todo lo que puede hacer es proporcionar menos información sobre la entidad oculta. Todo lo que el cliente necesita saber para generar el efecto de distorsión es que hay algo oculto en esa posición. Pero no necesita saber nada específico al respecto, como qué es exactamente, cuánta salud le queda y qué está haciendo en este momento. Dependiendo de su juego, eso solo puede ser un déficit de información que cambia el juego para el jugador.

— Philipp
fuente

66

Con "menos información" también viene "información menos precisa". Elija un desplazamiento de (digamos) 10 pies en una sola dirección aleatoria que se mantenga en el lado del servidor y envíe esa ubicación en su lugar. En otros encuentros aleatorios, agregue caracteres falsos y brillantes "¿Viste eso? Pensé que había visto algo allí".

— Keeta - reinstalar a Mónica el

2

@Keeta si utiliza esto, deseará suavizar (es decir, no generar un valor completamente aleatorio cada vez) con un filtro de señal o con algún tipo de Paseo aleatorio hacia la dirección de la entidad. Si es demasiado nervioso, entonces es realmente obvio a la vista, por lo que deberá equilibrar la capacidad del jugador para ocultarse durante el movimiento y ocultarse cuando se queda quieto. Este último será y debería ser más efectivo.

— Nate Diamond el

@NateDiamond Sí, exactamente. Es por eso que afirmo que el servidor crea un desplazamiento específico de la ubicación real. Luego, a medida que el actor real se mueve, el desplazamiento hará que el brillo también se mueva. Al observar cuidadosamente el brillo mientras se mueve, puede deducir dónde está el actor real, pero eso requiere algo de trabajo. Si la invisibilidad fuera real y causara este brillo en la vida real, imagino que este enfoque extra es exactamente lo que se necesitaría para superar la invisibilidad.

— Keeta - reinstalar a Monica el

Hubo una modificación interesante, y la única que realmente funcionó, de ioquake3 para hacer un servidor a prueba de wallhack . La idea era verificar en el servidor si un jugador A podía ver a otro jugador B (es decir, sin paredes ni otra separación que bloqueara la vista) antes de decidir si el jugador A debería recibir la información de posición de B. Esto ha demostrado ser muy efectivo contra wallhacks, ya que se volvieron inútiles. Entonces, el punto final es que la única forma de garantizar que nadie manipule los datos es no darles ninguna información.

— Gaborous

@gaborous es un cheque costoso, especialmente para cada jugador en cada tic. Puede muy bien ser un gasto que valga la pena, pero es algo que el desarrollador tendrá que considerar en el costo y las capacidades del servidor.

— Nate Diamond

1

Sí, cualquier información que envíe al cliente puede mostrarse más obviamente de lo que pretendía. Pero aquí está el truco:

Mitigar el impacto

Claro, el cliente puede tener alguna información, pero al pensar cuidadosamente en qué información está dispuesto a compartir, y en lo que los jugadores pueden hacer con ella, al menos puede mitigar el impacto de los ataques de los clientes.

1. ¿Qué observa el jugador?

Verá el personaje con características en el acto: en este caso, el cliente tendrá toda la información y los piratas informáticos simplemente pueden deshacer la capa
Ve algo en el acto: en este caso, el cliente tiene información de ubicación. Puede hacer que la ubicación sea obvia, pero aún debe ocultarse otra información.
Observas algo pero no está en el lugar

a. Ves algo pero no está en el lugar (el puente o el arbusto se mueve, pero es grande, por lo que no sabes a dónde apuntar; los pasos solo se hacen visibles con un retraso de 2 segundos): en este caso, el cliente solo sabe que hay algo, pero no dónde / qué exactamente.

si. Observa algo de una manera diferente (sonido si hay algo en el área; indicación de proximidad como un radar con o sin dirección)

La captura de pantalla en la pregunta parece estar entre 1 y 2, ya que probablemente se basa en información limitada, pero aún puede ver el esquema que podría revelar cierta información.

2. ¿Qué puede hacer el jugador?

Suponga que cree que alguien está en la coordenada XY, ¿qué puede hacer? Aquí hay algunas opciones típicas:

Agresor

Puedes atacarlo como si no estuviera envuelto
Puedes atacarlo con ataques / trampas AOA que lo desenmascaran o no
Puedes desbloquearlo activamente y solo atacarlo después
No puedes atacarlo en absoluto

Moviente

Cuando comienzas a moverte, notas que el motor te lleva misteriosamente a un desvío
Empiezas a caminar hacia tu meta normalmente, pero cuando alcanzas al personaje oculto te mueves a su alrededor o te detienes
No te bloquea el personaje oculto

Si la selección de ruta normalmente se realiza del lado del cliente

— Dennis
fuente

Gracias por tu contribución. Estaba planeando permitir que las personas se toparan con personajes invisibles de todos modos, porque eso es algo que el servidor puede calcular y manejar. La idea del sonido es clara, y cambiar el sonido de una manera sutil (tensión, piensa Jaws ) sería genial, pero ¿eso no se reemplazaría fácilmente con, por ejemplo, un archivo de sonido más fuerte o incluso un archivo de voz que diga ALGUNO CIERRE ES ROBADO ?

— Underflow

1

Otra idea en la línea de 'a': un brillo podría aparecer aleatoriamente en algún lugar cerca del jugador encubierto, pero no en su ubicación exacta. Si el servidor solo envía la posición del brillo, el cliente realmente no puede hacer mucha ingeniería inversa al respecto. De hecho, incluso si el jugador encubierto fuera completamente visible, esto seguiría funcionando como mecánico.

— Jezzamon

1

@Jezzamon sí, algún tipo de mecánica de 'desplazamiento' también sería genial. Sin embargo, en la situación de la capa que no funcionaría: no quiero castigar a los jugadores que están pendientes de relucir; tendrían que tener la ubicación "exacta" del reluciente para apuntar, por ejemplo, disparos de habilidades.

— Underflow

-2

El efecto dominó podría hacerse a través del código de sombreador. Puede deshabilitar el uso de textura en este modo para que el simple cambio de textura ya no sea un problema.

En 3D, cuando el modelo entra en juego, aún puede cambiar el sombreador a uno que simule la refracción, utilizando solo la superficie del modelo, descartando el color. Incluso cuando el modelo se reemplaza de alguna manera, el efecto permanece.

Modificar el sombreador precompilado sería tan difícil como modificar el código del juego y creo que es un nivel más difícil que algunas búsquedas de textura en los archivos del juego.

— Marte
fuente

3

Te perdiste la pregunta real. No se trataba de cómo crear técnicamente ese efecto de distorsión. Se trataba de cómo dar al cliente la información sobre dónde presentarla sin darle información útil que pueda exponer al jugador.

— Philipp

1

Bueno, os quiero hacer:

Which means that players that change the texture or model or even the game code itself could render the cloak mechanic useless

. Y no veo por qué me perdí la pregunta

whether there is some way to implement cloaking (with a 'shimmer', à la HotS), without having the issue that crafty players can modify the game (data)

. A: anuncia camuflaje con brillo, B: es más difícil de modificar que el simple cambio de textura. DONDE renderizar realmente es otro lado. Si la posición es lo único que necesitamos para aplicar el efecto dominó, debería ser la única información enviada al jugador.

— Marte el

2

He desarrollado hacks del lado del cliente en el pasado. La noción de que es más difícil modificar los sombreadores es muy, muy engañosa. Sí, detiene la forma de ataque más básica posible, pero cualquiera con Google-fu decente podría resolverlo en una tarde. Ahora enfrente su juego contra un hacker decente y vea cuánto tiempo lleva hasta que se llenen del lado del cliente.

Copie y pegue su comentario a cada respuesta aquí, ya que cualquier cosa del lado del cliente puede ser explotada. Sé que no es tan difícil modificar el código (hay bots, hacks, modificaciones en los juegos AAA), pero me resulta más fácil buscar textura semitransparente en los archivos del juego que buscar instrucciones específicas del efecto de ondulación del sombreador. Por supuesto, si los archivos de sombreado son texto plano y apenas comprimidos, incluso un niño podría romperlo. Acabo de dar una respuesta, que se puede combinar con "menos datos pasados al jugador" para proporcionar un nivel de seguridad decente. Realmente no sé qué tiene de malo, ya que proporciona una solución real

— Marte

@Thebluefish para ser justos, es por esto que los desarrolladores se alejaron de gastar recursos tratando de detener las trampas, y en su lugar gastaron recursos en métodos muy intrincados, oscuros y bien construidos para detectar trampas y prohibir directamente a los jugadores infractores de sus plataformas ... (obviamente consulte sistemas como el VAC de Steam).

— Trotski94

¿Cómo puedo implementar el encubrimiento multijugador con imágenes que resisten el pirateo del lado del cliente?

Mitigar el impacto

1. ¿Qué observa el jugador?

2. ¿Qué puede hacer el jugador?

Agresor

Moviente