Come posso contrassegnare i livelli come "completi" in un modo che impedisce di barare?

Le mie prime riflessioni sulla marcatura dei livelli sono solo scrivere le informazioni in un file al completamento del livello e caricarle una volta che l'app viene riaperta. Ma come potrei impedire che ciò manometta e prevenire barare?

La memorizzazione delle informazioni di completamento in un file locale è un metodo semplice e perfettamente accettabile per farlo. Fondamentalmente, questo è ciò che ogni gioco farà per tenere traccia dei progressi (in qualche modo, anche se i formati specifici utilizzati per i dati e il meccanismo di archiviazione differiranno).

È più difficile proteggere il file da manomissioni. Se non c'è motivo convincente (nessun vantaggio da ottenere per il giocatore, nessuna ricompensa, ecc.) Di solito puoi cavartela senza preoccuparti.

Ma se si fa attenzione, e voi e se si può ragionevolmente aspettare che la vostra piattaforma è chiusa (console e dispositivi non-jailbroken iOS-, per esempio) anche voi non c'è bisogno di preoccuparsi troppo. Normalmente l'utente non sarà fisicamente in grado di accedere al file per manometterlo (purché si utilizzino le API del sistema operativo appropriate per archiviare i dati in posizioni "private" e pubbliche (ad esempio, archiviando questo file nell'iCloud Drive dell'utente su iOS probabilmente non è una grande idea).

Se sei assolutamente preoccupato di manomettere il punto in cui ciò non deve accadere (ad esempio, quando un giocatore ha un vantaggio che ha più livelli completati), devi archiviare il lato server dei dati. Tutto ciò che viene archiviato sul lato client può in definitiva essere compromesso e non dovrebbe essere attendibile: è la macchina dell'utente, nelle sue mani. La dinamica di controllo non è a tuo favore.

Ovviamente non è assolutamente impossibile hackerare i file archiviati sul lato server, ma è molto più difficile se si dispone di un ragionevole sistema di contabilità.

È possibile creare un file di riproduzione come prova del lavoro mentre il lettore sta giocando. Avvia il gioco, salva le condizioni di partenza tra cui il nome del livello e il seme pseudocasuale, registra gli stati di input con timestamp esatti (movimenti del mouse, pressioni di tasti o pulsanti, ecc.) Che il livello di input del gioco passa al suo livello logico, e ferma registrare una volta raggiunto l'obiettivo. È possibile comprimere un registro di input con codifica run-length (RLE) in modo che solo le modifiche negli stati dei pulsanti (pressioni, rilasci e simili) causino eventi di registro. Dalle condizioni iniziali e dal registro di input, puoi verificare il completamento dell'obiettivo riproducendo gli input nella fisica e nell'IA del gioco.

I registri come questo hanno diverse applicazioni che sono familiari ai giocatori di videogiochi, in particolare i giochi emulati. I giocatori possono rivedere una partita localmente da un registro per cercare difetti di strategia o vantarsi con gli amici locali. La modalità di attrazione del gioco può consistere in registri per i livelli selezionati. Il netplay nei giochi che utilizzano il motore GGPO è strutturato in modo simile, con un ritardo di alcuni fotogrammi tra l'input e il motore di gioco in modo da consentire il tempo in cui l'input dell'altro giocatore arriva attraverso Internet. E puoi richiedere ai partecipanti della classifica di caricare il registro, quindi il tuo server lo eseguirà in avanti veloce su una copia ridotta del gioco senza motore grafico. Per prevenire un attacco di rigiocamento in cui un giocatore carica il registro di un altro, le informazioni utilizzate per seminare il generatore di numeri pseudocasuali del gioco possono includere l'ID utente della classifica del giocatore. In questo modo il server può confrontarli,

Alcuni giocatori estremamente dedicati costruiranno manualmente un registro di input che costituisce una prova del lavoro. Questo si chiama "speedrun assistito da utensili". Se non vuoi TAS nelle tue classifiche pubbliche, puoi richiedere giocate ai livelli più alti della competizione mentre sei connesso a Internet. Il server inviava un valore chiave ogni pochi secondi e il client inviava il registro di input in tempo reale come se fosse netplay, crittografato con quella chiave. Questa chiave cambia ogni pochi secondi e nei giochi che usano una sorta di elemento casuale, può ridimensionare il generatore di numeri pseudocasuali. Se un ritardo prolungato tra l'invio di una chiave e la ricezione dei pacchetti di input corrispondenti supera alcuni secondi, possiamo supporre che l'utente stia provando qualcosa di "divertente".

Se vuoi farlo totalmente sul lato client e non consideri l'archiviazione privata fornita dalla tua piattaforma abbastanza sicura (ad esempio se ci sono soldi reali coinvolti nel completamento dei livelli), ciò di cui hai bisogno è una prova del lavoro. Il tuo file di salvataggio deve contenere informazioni progettate in modo tale che la creazione delle informazioni sia difficile da calcolare se non hai completato il livello associato, ma facile da verificare da parte di terzi che non ha necessariamente completato quel determinato livello (preferibilmente senza dover conoscere la soluzione stessa). Maggiore è la differenza nella difficoltà di calcolare la prova del lavoro prima e dopo aver completato il livello, più sicura è la prova del lavoro.

Sfortunatamente, questa prova di lavoro deve essere tale da essere legata al gameplay, quindi non esiste un modo generico per farlo per giochi arbitrari e il tuo eseguibile di gioco non deve contenere la soluzione al gioco in alcun modo, altrimenti è abbastanza facile estrarre la prova del lavoro dall'eseguibile. Nella maggior parte dei casi, dovrai quasi sempre progettare in modo specifico il tuo gameplay attorno a questo particolare requisito per rendere una prova del lavoro a prova di imbrogli, quindi perderai anche un po 'di libertà creativa.

Ad esempio, diciamo un gioco del Sudoku, la prova del lavoro potrebbe essere la scheda Sudoku completata (nota che la scheda deve essere generata da una terza parte di fiducia, poiché la maggior parte dell'algoritmo di generazione delle schede di Sudoku deve precalcolare la soluzione, indebolendo la prova di funziona se è fatto sul client). O un gioco di factoring di un grande numero composto, la prova del lavoro sono i fattori primi (chiamerei tale gioco RSA vs NSA).

Per essere veramente sicuro, il tuo gioco deve contenere alcuni elementi casuali, perché se il tuo gioco è totalmente deterministico, è possibile imbrogliare copiando la prova del lavoro da qualcun altro che ha completato il livello (questo è un attacco di replay).

L'obiettivo della prova del lavoro è rendere i trucchi almeno difficili quanto la creazione di un bot per il gioco. Quindi, per imbrogliare in una partita di Sudoku, dovrai avere un solutore di Sudoku, ecc.

Questo è estremamente difficile. Se è un gioco per giocatore singolo, è meglio mantenere la tua libertà creativa e non preoccuparti di barare. È il loro gioco, l'hanno comprato e se imbrogliano, ciò non influisce sui profitti. Oppure trasformalo in un gioco basato su server e fai tutte le tue logiche di gioco importanti nel server.

Se preferisci utilizzare un file esterno per conservare le informazioni di salvataggio ed è in un luogo che potrebbe essere manomesso dagli utenti, potresti voler leggere su come funziona la crittografia e utilizzarlo per impedire a chiunque di apportare modifiche significative al file. Qualcosa come un Feistel Cipher dovrebbe essere un buon punto di partenza e sarebbe sufficiente per fermare qualcuno senza molto tempo e know-how dalla modifica di un file di salvataggio. http://en.wikipedia.org/wiki/Feistel_cipher

A parte questo, Josh ha colpito l'unghia in testa quando si tratta di archiviazione lato client e server.

Se qualcuno è in grado di esaminare il binario e scoprire l'algoritmo, non sarai mai in grado di impedirlo, quindi non preoccuparti.

Per interrompere semplicemente usa un hash crittografico!

Supponi di avere questo:

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

È davvero semplice ma significa che è necessario scrivere un codice alla fine del file, quindi analizzare quel file come al solito e fare computeHash(levelListReadFromFile);

Se quel codice hash = è stato letto nel file, allora è MOLTO PROBABILE "legittimo". Con questo intendo ... qualcuno con un editor esadecimale non lo spezzerà, ci vorrà qualcuno che conosca le loro cose.

Favorisci sempre l'archiviazione locale BTW - a meno che non sia ovviamente un MMO, le persone non vogliono che tu usi i loro dati, salga sui treni e faccia tutto il genere. Odio i programmi che richiedono l'accesso a Internet senza una buona ragione.