Como posso marcar os níveis como "completos" de forma a evitar trapaças?

Meus primeiros pensamentos sobre marcar níveis concluídos são apenas gravar as informações em um arquivo após a conclusão do nível e carregá-las assim que o aplicativo for aberto novamente. Mas como eu poderia manter isso a salvo de adulterações e evitar trapaças?

Armazenar as informações de conclusão em um arquivo local é um método simples e perfeitamente aceitável de fazer isso. Fundamentalmente, é isso que todo jogo fará para acompanhar o progresso (de alguma forma, embora os formatos específicos usados ​​para os dados e o mecanismo de armazenamento sejam diferentes).

Proteger o arquivo contra adulteração é mais difícil. Se não houver uma razão convincente (nenhuma vantagem a ser conquistada pelo jogador, nenhuma recompensa etc.), geralmente você pode se safar sem se importar.

Mas se você faz cuidado, e você e se você pode razoavelmente esperar que sua plataforma está fechado (consoles e dispositivos não-jailbroken-iOS, por exemplo), você também não precisa se preocupar muito. Normalmente, o usuário não poderá acessar fisicamente o arquivo para adulterá-lo (desde que você use as APIs apropriadas do SO para armazenar os dados em locais "privados" e públicos (por exemplo, armazenar esse arquivo no iCloud Drive do usuário no iOS provavelmente não é uma ótima ideia).

Se você está absolutamente preocupado em adulterar o ponto em que isso não deve acontecer (por exemplo, onde há uma vantagem a ser conquistada por um jogador com mais níveis concluídos), você precisa armazenar o servidor de dados. Qualquer coisa armazenada no lado do cliente pode ser comprometida e não deve ser confiável: é a máquina do usuário, nas mãos do usuário. A dinâmica de controle não está a seu favor.

Também não é estritamente impossível invadir arquivos armazenados no servidor, é claro, mas é muito mais difícil se você tiver um sistema de contabilidade razoável.

Você pode criar um arquivo de repetição como prova do trabalho enquanto o player estiver tocando. Inicie o jogo, salve as condições iniciais, incluindo o nome do nível e a semente pseudoaleatória, registre os estados de entrada com data e hora exata (movimentos do mouse, pressionar teclas ou botões, etc.) que a camada de entrada do jogo passa para a camada lógica e pare gravar assim que o objetivo for alcançado. Você pode compactar um log de entrada com RLE (codificação em tamanho de execução), para que apenas alterações nos estados dos botões (pressionamentos, liberações e similares) causem eventos de log. Nas condições iniciais e no registro de entrada, você pode verificar a conclusão do objetivo repetindo as entradas na física e na IA do jogo.

Logs como esse têm vários aplicativos familiares aos jogadores de videogames, jogos especialmente emulados. Os jogadores podem assistir a um jogo localmente a partir de um registro para procurar falhas de estratégia ou se gabar para os amigos locais. O modo de atração do seu jogo pode consistir em registros para níveis selecionados. A netplay em jogos usando o mecanismo GGPO é estruturada da mesma forma, com um atraso de alguns quadros entre a entrada e o mecanismo do jogo, a fim de permitir tempo para a entrada do outro jogador chegar pela Internet. E você pode exigir que os participantes da tabela de classificação enviem o log e, em seguida, o servidor o executará em uma cópia de corte do jogo sem mecanismo de gráficos. Para evitar um ataque de repetição no qual um jogador carrega o log de outro, as informações usadas para propagar o gerador de números pseudo-aleatórios do jogo podem incluir o ID do usuário no placar do jogador. Dessa forma, o servidor pode compará-los,

Alguns players extremamente dedicados criarão manualmente um log de entrada que constitua uma prova de trabalho. Isso é chamado de "speedrun assistido por ferramenta". Se você não quiser o TAS em suas tabelas de classificação públicas, poderá exigir que as jogadas nos níveis mais altos da competição sejam feitas enquanto estiver conectado à Internet. O servidor enviava um valor de chave a cada poucos segundos e o cliente enviava o log de entrada em tempo real como se fosse netplay, criptografado com essa chave. Essa tecla muda a cada poucos segundos e, nos jogos que usam algum tipo de elemento aleatório, pode reenviar o gerador de números pseudoaleatórios. Se o atraso sustentado entre o envio de uma chave e o recebimento dos pacotes de entrada correspondentes exceder vários segundos, podemos assumir que o usuário está tentando algo "engraçado".

Se você quiser fazer isso totalmente no lado do cliente e não considerar o armazenamento privado fornecido por sua plataforma seguro o suficiente (por exemplo, se houver dinheiro real envolvido na conclusão dos níveis), o que você precisa é uma prova de trabalho. Seu arquivo salvo deve conter informações projetadas para dificultar o cálculo, a menos que você tenha concluído o nível associado, mas fácil de verificar por terceiros que não necessariamente concluíram esse nível específico (de preferência sem precisar conhecer a solução em si). Quanto maior a diferença na dificuldade de calcular a prova de trabalho antes e depois de concluir o nível, mais segura é a prova de trabalho.

Infelizmente, porém, essa prova de trabalho deve estar vinculada à jogabilidade, portanto não existe uma maneira genérica de fazê-lo em jogos arbitrários, e o executável do seu jogo não deve conter a solução para o jogo de nenhuma maneira ou, caso contrário, é bastante fácil extrair a prova de trabalho do executável. Na maioria dos casos, você quase sempre precisará projetar especificamente sua jogabilidade em torno desse requisito específico para fazer com que a prova do trabalho seja à prova de trapaças, para que você também perca alguma liberdade criativa.

Por exemplo, digamos que um jogo de Sudoku, a prova do trabalho possa ser o quadro completo do Sudoku (observe que o quadro deve ser gerado por terceiros confiáveis, porque a maioria dos algoritmos de geração do quadro Sudoku precisa pré-calcular a solução, isso enfraquece a prova de funcione se for feito no cliente). Ou um jogo de fatorar um grande número composto, a prova do trabalho é o principal fator (eu chamaria esse jogo de RSA vs NSA).

Para ser realmente seguro, porém, seu jogo precisa conter alguns elementos aleatórios, porque se for totalmente determinístico, é possível enganar copiando a prova de trabalho de alguém que tenha concluído o nível (este é um ataque de repetição).

O objetivo da prova de trabalho é tornar a trapaça pelo menos tão difícil quanto criar um bot para o jogo. Então, para trapacear em um jogo de Sudoku, você precisará ter um solucionador de Sudoku, etc.

Isso é extremamente difícil. Se for um jogo para um jogador, é melhor manter sua liberdade criativa e não se preocupar com trapaças. É o jogo deles, eles o compraram e, se trapacearem, isso não afeta seus resultados. Ou ligue-o para um jogo baseado em servidor e faça toda a sua lógica de jogo importante no servidor.

Se você preferir usar um arquivo externo para armazenar informações salvas e ele estiver em um local que possa ser adulterado pelos usuários, você pode ler sobre como a criptografia funciona e usá-la para impedir que alguém possa fazer alterações significativas no Arquivo. Algo como uma Cifra Feistel deve ser um bom ponto de partida e seria suficiente para impedir alguém sem muito tempo e conhecimento de alterar um arquivo salvo. http://en.wikipedia.org/wiki/Feistel_cipher

Além disso, Josh acertou na cabeça quando se trata de armazenamento do lado do cliente e do servidor.

Se alguém é capaz de escolher o binário e descobrir o algoritmo - você nunca será capaz de impedir isso, então não se preocupe.

Para parar, basta usar um hash criptográfico!

Suponha que você tenha isso:

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

É realmente simples, mas significa que você precisa escrever um código no final do arquivo, depois analisá-lo como de costume e fazer computeHash(levelListReadFromFile);

SE esse hash = código for lido no arquivo, é MUITO PROVÁVEL "legítimo". Com isso eu quero dizer ... alguém com um editor hexadecimal não vai entender, é preciso alguém que saiba o que quer.

Sempre favorece o armazenamento local BTW - a menos que seja um MMO, obviamente, as pessoas não querem que você use seus dados, vá de trem e faça todo tipo de coisa. Eu odeio programas que exigem acesso à Internet sem um bom motivo.