Comment puis-je marquer les niveaux comme «terminés» de manière à empêcher la triche?

Mes premières réflexions sur le marquage des niveaux terminés consistent simplement à écrire les informations dans un fichier à la fin du niveau et à les charger une fois que l'application est à nouveau ouverte. Mais comment pourrais-je garder cela à l'abri de la falsification et empêcher la triche?

Le stockage des informations d'achèvement dans un fichier local est une méthode simple et parfaitement acceptable de le faire. Fondamentalement, c'est ce que chaque jeu fera pour suivre les progrès (d'une certaine manière, bien que les formats spécifiques utilisés pour les données et le mécanisme de stockage diffèrent).

La protection du fichier contre la falsification est plus difficile. S'il n'y a aucune raison impérieuse (aucun avantage à gagner par le joueur, aucune récompense, etc.), vous pouvez généralement vous en tirer sans vous soucier.

Mais si vous vous en souciez, et que vous et que vous pouvez raisonnablement vous attendre à ce que votre plate-forme soit fermée (consoles et appareils iOS non jailbreakés, par exemple), vous n'avez pas non plus à vous inquiéter trop. L'utilisateur ne sera normalement pas physiquement capable d'accéder au fichier pour l'altérer (à condition que vous utilisiez les API de système d'exploitation appropriées pour stocker les données dans des emplacements «privés» et publics (par exemple, en stockant ce fichier dans le lecteur iCloud de l'utilisateur sur iOS). n'est probablement pas une bonne idée).

Si vous êtes absolument préoccupé par la falsification au point où cela ne doit pas se produire (par exemple, lorsqu'un joueur a plus de niveaux à gagner), vous devez stocker les données côté serveur. Tout ce qui est stocké côté client peut finalement être compromis et ne doit pas faire confiance: c'est la machine de l'utilisateur, entre les mains de l'utilisateur. La dynamique de contrôle n'est tout simplement pas en votre faveur.

Il n'est pas strictement impossible de pirater des fichiers stockés côté serveur, bien sûr, mais c'est beaucoup plus difficile si vous avez un système de comptabilité raisonnable.

Vous pouvez créer un fichier de relecture comme preuve de travail pendant la lecture du lecteur. Démarrez le jeu, enregistrez les conditions de départ, y compris le nom du niveau et la graine pseudo-aléatoire, enregistrez les états d'entrée horodatés exacts (mouvements de la souris, pressions sur les touches ou les boutons, etc.) que la couche d'entrée de votre jeu passe à sa couche logique, et arrêtez l'enregistrement une fois l'objectif atteint. Vous pouvez compresser un journal d'entrée avec un encodage de longueur (RLE) de sorte que seuls les changements dans les états des boutons (pressions, relâchements, etc.) provoquent des événements de journal. À partir des conditions initiales et du journal des entrées, vous pouvez vérifier l'achèvement de l'objectif en rejouant les entrées dans la physique et l'IA du jeu.

Les journaux comme celui-ci ont plusieurs applications qui sont familières aux joueurs de jeux vidéo, en particulier les jeux émulés. Les joueurs peuvent revoir un jeu localement à partir d'un journal pour rechercher des failles de stratégie ou se vanter auprès d'amis locaux. Le mode d'attraction de votre jeu peut consister en des journaux pour les niveaux sélectionnés. Netplay dans les jeux utilisant le moteur GGPO est structuré de la même manière, avec un délai de quelques images entre l'entrée et le moteur de jeu afin de laisser le temps à l'entrée de l'autre joueur d'arriver via Internet. Et vous pouvez demander aux participants au classement de télécharger le journal, puis votre serveur l'exécutera en avance rapide sur une copie tronquée du jeu sans moteur graphique. Pour empêcher une attaque de relecture où un joueur télécharge le journal d'un autre, les informations utilisées pour amorcer le générateur de nombres pseudo-aléatoires du jeu peuvent inclure l'ID utilisateur du classement du joueur. De cette façon, le serveur peut les comparer,

Certains joueurs extrêmement dévoués construiront manuellement un journal d'entrée qui constitue une preuve de travail. C'est ce qu'on appelle un "speedrun assisté par outil". Si vous ne voulez pas que le TAS figure dans vos classements publics, vous pouvez exiger que les parties aux niveaux de compétition les plus élevés soient effectuées tout en étant connectés à Internet. Le serveur enverrait une valeur de clé toutes les quelques secondes, et le client enverrait le journal d'entrée en temps réel comme s'il s'agissait de netplay, chiffré avec cette clé. Cette clé change toutes les quelques secondes, et dans les jeux utilisant une sorte d'élément aléatoire, elle peut réamorcer le générateur de nombres pseudo-aléatoires. Si le décalage prolongé entre l'envoi d'une clé et la réception des paquets d'entrée correspondants dépasse plusieurs secondes, nous pouvons supposer que l'utilisateur essaie quelque chose de "drôle".

Si vous voulez le faire totalement du côté client et que vous ne considérez pas que le stockage privé fourni par votre plate-forme est suffisamment sécurisé (par exemple, s'il y a de l'argent réel impliqué dans l'achèvement des niveaux), vous avez besoin d'une preuve de travail. Votre fichier de sauvegarde doit contenir des informations conçues de telle sorte que la création des informations est difficile à calculer à moins d'avoir terminé le niveau associé, mais facile à vérifier par un tiers qui n'a pas nécessairement atteint ce niveau particulier (de préférence sans avoir à le faire connaître la solution elle-même). Plus la différence dans la difficulté de calculer la preuve de travail avant et après avoir terminé le niveau est grande, plus la preuve de travail est sûre.

Malheureusement, cette preuve de travail doit être telle qu'elle soit liée au gameplay, il n'y a donc pas de moyen générique pour les jeux arbitraires, et l'exécutable de votre jeu ne doit en aucun cas contenir la solution du jeu, sinon il est assez facile d'extraire la preuve de travail de l'exécutable. Dans la plupart des cas, vous devrez presque toujours concevoir spécifiquement votre gameplay autour de cette exigence particulière pour faire une preuve de travail à l'épreuve de la triche, de sorte que vous perdrez également une certaine liberté créative.

Par exemple, disons un jeu de Sudoku, la preuve de travail pourrait être la carte Sudoku terminée (notez que la carte doit être générée par un tiers de confiance, car la plupart des algorithmes de génération de carte Sudoku doivent précalculer la solution, ce qui affaiblit la preuve de fonctionner si c'est fait sur le client). Ou un jeu d'affacturage d'un grand nombre composite, la preuve du travail est le facteur premier (j'appellerais un tel jeu RSA vs NSA).

Pour être vraiment sûr, votre jeu doit contenir des éléments aléatoires, car si votre jeu est totalement déterministe, il est possible de tricher en copiant la preuve de travail de quelqu'un d'autre qui a terminé le niveau (il s'agit d'une attaque par rejeu).

Le but de la preuve de travail est de rendre la tricherie au moins aussi difficile que de créer un bot pour le jeu. Donc, pour tricher sur un jeu Sudoku, vous aurez besoin d'un solveur Sudoku, etc.

C'est extrêmement difficile. S'il s'agit d'un jeu solo, il vaut mieux garder votre liberté créative et ne vous inquiétez pas de tricher. C'est leur jeu, ils l'ont acheté et s'ils trichent, cela n'affecte pas votre résultat net. Ou transformez-le en jeu basé sur serveur et faites toute votre logique de jeu importante sur le serveur.

Si vous préférez utiliser un fichier externe pour conserver les informations de sauvegarde et que ces informations se trouvent dans un endroit susceptible d'être altéré par les utilisateurs, vous souhaiterez peut-être en savoir plus sur le fonctionnement du cryptage et l'utiliser pour empêcher quiconque de pouvoir apporter des modifications significatives à la fichier. Quelque chose comme un chiffrement Feistel devrait être un bon point de départ et serait suffisant pour empêcher quelqu'un sans beaucoup de temps et de savoir-faire de modifier un fichier de sauvegarde. http://en.wikipedia.org/wiki/Feistel_cipher

En plus de cela, Josh a mis le doigt sur la tête en matière de stockage côté client et serveur.

Si quelqu'un est capable de parcourir le binaire et de découvrir l'algorithme - vous ne pourrez jamais vraiment empêcher cela, alors ne vous embêtez pas.

Pour arrêter, utilisez simplement un hachage cryptographique!

Supposons que vous ayez ceci:

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

C'est vraiment simple mais cela signifie que vous devez écrire un code à la fin du fichier, puis analyser ce fichier comme d'habitude et faire computeHash(levelListReadFromFile);

SI ce hachage = code lu dans le fichier, il est TRÈS PROBABLEMENT "légitime". J'entends par là ... quelqu'un avec un éditeur hexadécimal ne le craquera pas, il faudra quelqu'un qui connaît son affaire.

Privilégiez toujours le stockage local BTW - à moins qu'il ne s'agisse évidemment d'un MMO, les gens ne veulent pas que vous utilisiez leurs données, montez dans les trains et fassiez toutes sortes de choses. Je déteste les programmes qui nécessitent un accès à Internet sans raison valable.