2009-06-06 22 views
32

Si está escribiendo un juego, debe pensar en los tramposos y en cómo evitar que hagan trampa.¿Cómo prevenir las trampas en nuestros juegos (multijugador)?

No creo que solo los juegos de multijugador de mmo, sino también juegos de un solo jugador o "en casa" p2p mp también.

Cuando el juego se basa completamente en una arquitectura de servidor-cliente, el trabajo está casi hecho, creo, pero también hay hacks de pared u otra cosa.

Hice mi propio juego p2p y algún tiempo después aparecieron los tramposos. Eran solo scriptkiddies que usaban cheat engine y probaban speedhacks y hacks de memoria.

La mayoría de los ganchos Speedhacks gettickcount. Resolví Speedhackers por el siguiente truco simple. Solo estoy rastreando el valor de time()-GetTickCount() y si la diferencia cambia hay trampa.

Las corrupciones de memoria se pueden resolver manteniendo una copia hash en algún lugar y moviéndola siempre y volviéndola a generar con un valor aleatorio. La falta de coincidencia causa un bloqueo.

para solucionar motor de trucos en absoluto, simplemente marque:

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0) 
{ 
    // Cheat Engine runs. 
} 

(un amigo me dijo esto, no he probado todavía.)

Estos trucos ordenados a cabo la mayoría de los tramposos. Pero, por supuesto, hay más técnicas de engaño. Abrí este wiki, para analizar más otras técnicas de trampas y la forma de evitarlas.

+1

Si su juego usa partidas guardadas, debe verificar la edición del juego de salvar y corromper – Jim

Respuesta

54

No creo que debas hacer nada para evitar las trampas en juegos para un solo jugador. Sus usuarios compraron el juego, deberían poder hacer trampa si lo desean, siempre y cuando no jueguen contra otros.

Aquí hay algunas cosas que he hecho. Estos se realizaron principalmente para sistemas anti-trampas en juegos de torneos, donde el dinero está en juego, y ciertos niveles de intrusión en el sistema del usuario se consideran aceptables. Sería cuidadoso al hacer algunas de estas cosas en juegos casuales, ya que si tu juego no es estable existe la posibilidad de causar problemas con su sistema.

1) Siempre que sea posible, "Nunca confíes en el cliente" es el principio más seguro que debes cumplir. Realice todas las acciones en el servidor y solo dele al cliente todo el conocimiento necesario para mostrar lo que debería poder ver en la pantalla en cualquier momento. es decir, si un cliente no conoce la posición de un jugador que está escondido detrás de una pared, un truco de pared no le hará ningún bien al usuario. Para los juegos de acción de alta velocidad esto puede ser extremadamente difícil, especialmente ahora que las sombras en tiempo real son la norma, donde el usuario puede necesitar ver una sombra incluso si el cuerpo del jugador es visible, pero siempre debe ser en la parte superior de tus opciones También es extremadamente difícil de hacer en juegos peer-to-peer, pero hay formas de limitar el conocimiento entre pares. Solo cuando se convierte en un rendimiento prohibitivo, o fuera de su presupuesto de tiempo/dinero, deben considerarse los siguientes elementos.

2) Abra todos los demás procesos y enganche sus funciones WriteProcessMemory para que no puedan escribir en la memoria en el proceso de su juego. Hecho en este paso, bloqueará el 90% de todos los trucos y trampas.

3) Haga lo mismo, conectando las diversas funciones de emulación de mouse y teclado. Esto evitará muchos aimbots y otros tipos de bots de automatización.

4) Enganche en las funciones VirtualProtectEx/VirtualAllocEx/etc en el proceso de su juego y controle qué módulos están cambiando los niveles de protección o asignando nuevos trozos de memoria. Tienes que ser astuto con esto para evitar que sea demasiado intensivo en la CPU cuando tu juego hace muchas asignaciones, pero se puede hacer.

5) Enganche en las funciones de LoadLibrary y supervise las DLL que se cargan dinámicamente para evitar la inyección de DLL.

6) Usa alguna codificación polimórfica ligera en las conexiones de tu juego.

7) Use algunas técnicas anti-depuración para evitar que los depuradores se adhieran a sus procesos. Google anti-depuración y deberías poder encontrar muchas cosas.

8) Utilice un empacador de PE personalizado para evitar el desmontaje útil de su juego.

9) Enganche sus funciones y métodos OpenGL o Direct3D que se ocupan de la transparencia y la mezcla alfa.

10) Si utiliza sombreadores, suma de comprobación sus sombreadores y los valores constantes del sombreador.

11) Utilice técnicas adicionales de eliminación de oclusiones en los personajes del jugador para evitar que se rendericen cuando la línea de visión esté bloqueada por otra geometría. Puede o no ayudar con su rendimiento también, pero evitará muchos wallhacks.

+10

+1 para evitar las trampas en el modo de un solo jugador. –

+2

P2P = Peer to peer, es decir, no solo jugador. Aunque estoy de acuerdo con no perder el tiempo protegiendo un juego para un solo jugador, siempre y cuando las trampas no puedan interferir de ninguna manera con otros jugadores (por ejemplo, listas de mejores puntuaciones en línea o similares). –

+2

+1 para obtener una lista completa de cosas que hacer. –

16

Puede encontrar este documento en Cheat Proof Game Protocols interesante. Son todas variaciones sobre la misma idea: usar hashes como una promesa, y luego revelar el significado de la promesa hash una vez que se cumplen las condiciones sobre el comportamiento de otros jugadores. Es complicado y tiene un impacto en el rendimiento, pero algunas de las ideas pueden ser útiles, particularmente para los juegos P2P.

+1

el enlace está muerto; [esta pregunta] (http://gamedev.stackexchange.com/questions/47145/peer-to-peer-hostless-competitive-games-of-chance) en el juegodev stackexchange tiene algunos excelentes enlaces (en vivo) – aeosynth

+2

Archive.org link: https://web.archive.org/web/20091123061710/http://prisms.cs.umass.edu/brian/pubs/baughman.infocom01.pdf – deltaray

5

Cuando el juego se basa completamente en una arquitectura de servidor-cliente, el trabajo casi está hecho, creo, pero también hay hacks de pared u otra cosa.

Si no puede mover la mayor parte de las lógicas que se ejecutan en el lado del servidor, por lo menos tratar de compartir el menor estado de la forma más realista posible durante cada fase de juego, en otras palabras: mantener el modo de juego activo de cada jugador en cuenta y solo comparta información que sea realmente relevante en ese momento.

Esto no solo reducirá la posibilidad de hacer trampas, sino que también reducirá el tráfico causado por su protocolo, es decir, mejorará la eficiencia.

Esta es una técnica que en sí misma se conoce desde hace tiempo y se aplica en la industria del juego/simulación para mejorar la eficiencia cuando se renderizan grandes escenas en 3D.

Allí, "eliminación de troncos" se utiliza para determinar qué partes de una escena son realmente visibles, de modo que solo se representan las partes relevantes.

De manera similar, la misma técnica se puede usar para restringir que los clientes multijugador reciban solo ciertas actualizaciones/información si son realmente relevantes, p. si otros clientes están realmente dentro de un "rango de relevancia ", para que otros clientes puedan recuperar las actualizaciones correspondientes.

Aún así, diferencie entre relevancia y "visibilidad": es posible que dos jugadores separados por una puerta no se "vean" entre sí, pero dependiendo del entorno, pueden escucharse muy bien. Por lo tanto, diferencie entre los diferentes tipos de "visibilidad": la propagación del estado audible no necesariamente implica la propagación de la posición real del jugador en las coordenadas del juego. Lo mismo se aplica a la inversa: solo porque "ves" a un jugador, no necesariamente tienes derecho a escuchar al cliente (por ejemplo, imagina un alcance en un rifle).

En otras palabras, intente acoplar libremente los paquetes de actualización que admite, de modo que no tengan dependencias mutuas entre sí, y también puedan propagarse/suscribirse de forma independiente.

trampa puede ser controlada en gran parte simplemente mediante la aplicación de encapsulación y datos que ocultan los mecanismos adecuada, de modo que los clientes de varios jugadores por lo general no comparten el estado global, pero el estado compartido es en cambio depende directamente de contexto activo del reproductor (posición, rumbo, orientación, velocidad etc.)

+0

Por supuesto, si hay la menor posibilidad de que una parte de un el jugador será visible para otro jugador, la posición de ese jugador tendrá que ser enviada al cliente haciendo un trabajo de hackeo en algunos casos. –

+0

Creo que olvidó mencionar que esto no es trivial en cuanto al esfuerzo y tiene cierto impacto en el rendimiento. Además, no funcionará en absoluto en muchas circunstancias. "Gestión de intereses" es el término para buscar en Google. – marsbear

Cuestiones relacionadas