¿Cómo puedo marcar los niveles como "completos" de una manera que evite las trampas?

Lo primero que pienso acerca de marcar niveles completos es escribir la información en un archivo al finalizar el nivel y cargarla una vez que la aplicación se abra nuevamente. Pero, ¿cómo podría evitar que esto se manipule y evitar las trampas?

Almacenar la información de finalización en un archivo local es un método simple y perfectamente aceptable para hacerlo. Básicamente, esto es lo que hará cada juego para seguir el progreso (de alguna manera, aunque los formatos específicos utilizados para los datos y el mecanismo de almacenamiento serán diferentes).

Proteger el archivo de la manipulación es más difícil. Si no hay una razón convincente (ninguna ventaja para el jugador, ninguna recompensa, etcétera), generalmente puede salirse con la suya sin importarle.

Pero si lo hace la atención, y usted y si se puede esperar razonablemente que su plataforma está cerrado (consolas y dispositivos con jailbreak no-IOS, por ejemplo) que también no tiene que preocuparse demasiado. El usuario normalmente no será físicamente capaz de acceder al archivo para manipularlo (siempre que use las API del sistema operativo apropiadas para almacenar los datos en ubicaciones "privadas" y públicas (por ejemplo, almacenar este archivo en la unidad iCloud Drive del usuario en iOS) probablemente no sea una gran idea).

Si está absolutamente preocupado por la manipulación hasta el punto en que esto no debe suceder (por ejemplo, cuando un jugador que tiene más niveles completados puede obtener una ventaja), debe almacenar el lado del servidor de datos. Cualquier cosa almacenada en el lado del cliente puede verse comprometida y no se debe confiar en ella: es la máquina del usuario, en manos del usuario. La dinámica de control simplemente no está a su favor.

Tampoco es estrictamente imposible hackear archivos almacenados del lado del servidor, por supuesto, pero es mucho más difícil si tienes un sistema de contabilidad razonable.

Puede crear un archivo de reproducción como prueba de trabajo mientras el jugador está jugando. Inicie el juego, guarde las condiciones de inicio, incluido el nombre del nivel y la semilla pseudoaleatoria, registre los estados de entrada marcados con el tiempo exacto (movimientos del mouse, pulsaciones de teclas o botones, etc.) que la capa de entrada de su juego pasa a su capa lógica y pare grabación una vez que se logra el objetivo. Puede comprimir un registro de entrada con codificación de longitud de ejecución (RLE) para que solo los cambios en los estados de los botones (pulsaciones, liberaciones y similares) provoquen eventos de registro. A partir de las condiciones iniciales y el registro de entrada, puedes verificar la finalización del objetivo al reproducir las entradas en la física y la IA del juego.

Registros como este tienen varias aplicaciones que los jugadores de videojuegos conocen., especialmente juegos emulados. Los jugadores pueden volver a mirar un juego localmente desde un registro para buscar fallas de estrategia o presumir ante amigos locales. El modo de atracción de tu juego puede consistir en registros para niveles seleccionados. Netplay en los juegos que usan el motor GGPO está estructurado de manera similar, con un retraso de unos pocos fotogramas entre la entrada y el motor del juego para dar tiempo a que la entrada del otro jugador llegue a través de Internet. Y puede exigir a los participantes de la tabla de clasificación que carguen el registro, y luego su servidor lo ejecutará en avance rápido en una copia reducida del juego sin motor gráfico. Para evitar un ataque de repetición en el que un jugador carga el registro de otro, la información utilizada para sembrar el generador de números pseudoaleatorios del juego puede incluir la identificación de usuario de la tabla de clasificación del jugador. De esta manera el servidor puede compararlos,

Algunos jugadores extremadamente dedicados construirán manualmente un registro de entrada que constituye una prueba de trabajo. Esto se llama "speedrun asistido por herramientas". Si no desea TAS en sus tablas de clasificación públicas, puede exigir que se realicen jugadas en los niveles más altos de la competencia mientras está conectado a Internet. El servidor enviaría un valor de clave cada pocos segundos, y el cliente enviaría el registro de entrada en tiempo real como si fuera netplay, cifrado con esa clave. Esta clave cambia cada pocos segundos, y en los juegos que usan algún tipo de elemento aleatorio, puede reiniciar el generador de números pseudoaleatorios. Si el retraso sostenido entre el envío de una clave y la recepción de los paquetes de entrada correspondientes excede varios segundos, podemos suponer que el usuario está intentando algo "divertido".

Si desea hacer esto totalmente en el lado del cliente y no considera que el almacenamiento privado proporcionado por su plataforma es lo suficientemente seguro (por ejemplo, si hay dinero real involucrado en completar los niveles), lo que necesita es una prueba de trabajo. Su archivo guardado debe contener una información diseñada de tal manera que crear la información sea difícil de calcular a menos que haya completado el nivel asociado, pero fácil de verificar por un tercero que no necesariamente ha completado ese nivel en particular (preferiblemente sin tener que Conozca la solución en sí). Cuanto mayor sea la diferencia en la dificultad de calcular la prueba de trabajo antes y después de completar el nivel, más segura será la prueba de trabajo.

Desafortunadamente, esta prueba de trabajo debe ser tal que esté vinculada a la jugabilidad, por lo que no hay una forma genérica de hacer esto para los juegos arbitrarios, y el ejecutable de su juego no debe contener la solución al juego de ninguna manera, o de lo contrario es bastante fácil extraer la prueba de trabajo del ejecutable. En la mayoría de los casos, casi siempre tendrá que diseñar específicamente su juego en torno a este requisito particular para hacer que una prueba de trabajo sea a prueba de trampas, por lo que también perderá algo de libertad creativa.

Por ejemplo, digamos un juego de Sudoku, la prueba de trabajo podría ser el tablero de Sudoku completo (tenga en cuenta que el tablero debe ser generado por un tercero confiable, porque la mayoría del algoritmo de generación de tablero de Sudoku necesita calcular previamente la solución, esto debilita la prueba de funciona si se hace en el cliente). O un juego de factorizar un gran número compuesto, la prueba del trabajo son los factores primos (yo llamaría a ese juego RSA vs NSA).

Sin embargo, para ser realmente seguro, tu juego debe contener algunos elementos aleatorios, porque si tu juego es totalmente determinista, es posible hacer trampa copiando la prueba de trabajo de otra persona que haya completado el nivel (este es un ataque de repetición).

El objetivo de la prueba de trabajo es hacer que las trampas sean al menos tan difíciles como crear un bot para el juego. Entonces, para hacer trampa en un juego de Sudoku, necesitarás tener un solucionador de Sudoku, etc.

Esto es extremadamente difícil. Si es un juego para un solo jugador, es mejor mantener tu libertad creativa y no preocuparte por hacer trampa. Es su juego, lo han comprado y si hacen trampa, eso no afecta su resultado final. O conviértalo en un juego basado en servidor y haga toda su lógica de juego importante en el servidor.

Si prefiere usar un archivo externo para guardar la información guardada y está en un lugar que los usuarios no puedan manipular, es posible que desee leer cómo funciona el cifrado y usarlo para evitar que cualquier persona pueda realizar cambios significativos en el archivo. Algo así como un cifrado Feistel debería ser un buen punto de partida y sería suficiente para detener a alguien sin mucho tiempo y conocimientos para cambiar un archivo guardado. http://en.wikipedia.org/wiki/Feistel_cipher

Aparte de eso, Josh ha dado en el clavo cuando se trata del almacenamiento del lado del cliente y del servidor.

Si alguien puede leer el binario y descubrir el algoritmo, nunca podrá evitarlo, así que no se moleste.

Para detenerse, simplemente use un hash criptográfico.

Supongamos que tienes esto:

function computeHash(levels) {
    code = "";
    for(level in levels) {
       code = hash(code+level+level.isComplete()+"MAGICSALT")
    }
}

Es realmente simple, pero significa que debe escribir un código al final del archivo, luego analizar ese archivo como de costumbre y hacer computeHash(levelListReadFromFile);

SI ese hash = código leído en el archivo, entonces es MUY PROBABLEMENTE "legítimo". Con esto quiero decir ... alguien con un editor hexadecimal no lo descifrará, se necesitará alguien que sepa sus cosas.

Siempre favorezca el almacenamiento local, por cierto, a menos que sea un MMO obviamente, la gente no quiere que use sus datos, vaya en trenes y haga todo tipo de cosas. Odio los programas que requieren acceso a internet sin una buena razón.