qual è il metodo o l'algoritmo più utilizzato per salvare lo stato del gioco (profili), i file di testo dei database come va la crittografia e le cose relative.
Ho visto Cesare IV usato mySQL.
eventuali suggerimenti.
qual è il metodo o l'algoritmo più utilizzato per salvare lo stato del gioco (profili), i file di testo dei database come va la crittografia e le cose relative.
Ho visto Cesare IV usato mySQL.
eventuali suggerimenti.
Risposte:
Sono abbastanza sicuro che il più delle volte sia fatto in un formato proprietario (binario), semplicemente scrivendo ogni variabile da qualunque struttura di stato del gioco usi in un file o rileggendolo in un'istanza della struttura. In C ++, ad esempio, puoi trattare un oggetto come un array di byte e semplicemente scriverlo () in un file o fread () dal file e ricondurlo nella sua forma oggetto.
Se si utilizza Java o un'altra lingua, è possibile scegliere di utilizzare la serializzazione per rendere l'attività davvero semplice. La spiegazione di Java è in fondo a questa risposta; altri linguaggi (di livello superiore a C ++) hanno sicuramente le loro librerie di serializzazione o funzioni integrate, che dovresti scegliere di usare. Non importa quanto inefficiente potrebbe essere la routine di serializzazione, lo spazio su disco rigido al giorno d'oggi è economico, specialmente quando lo stato del gioco non dovrebbe essere molto grande e ti impedisce di scrivere e mantenere tue routine di serializzazione.
Si dovrebbe assolutamente non utilizzare MySQL (basta leggere la prima frase di questa recensione ). Se hai davvero bisogno di un database relazionale per qualche motivo, usa SQLite ; è un sistema di database leggero ed esiste in un singolo file di database. Ma per la maggior parte dei giochi, i database relazionali non sono la strada da percorrere e le aziende che cercano di usarli finiscono per usarli come una tabella di ricerca di valori-chiave piuttosto che come un vero database relazionale.
Qualsiasi tipo di crittografia dei file del disco locale è solo offuscamento ; qualsiasi hacker annuserà i dati subito dopo che il tuo programma li decifrerà. Personalmente sono contrario a quel genere di cose, in particolare con le partite a un giocatore. La mia opinione è che i proprietari del gioco (pagando i clienti, intendiamoci) dovrebbero poter hackerare il gioco se lo desiderano. In alcuni casi può creare un maggiore senso di comunità e possono essere sviluppate "mod" per il tuo gioco che portano più clienti a te. L'esempio più recente che mi viene in mente è il portale in mod di Minecraft che è stato recentemente rilasciato. È pubblicato nei siti di notizie dei giocatori su Internet e puoi scommettere che ha spinto le vendite di Minecraft.
Se per qualche motivo sei abbastanza pazzo da usare Java per lo sviluppo di giochi come me, ecco una breve spiegazione della serializzazione in Java:
Conserva tutti i dati sullo stato del gioco in una classe, rendi la classe serializzabile implementando
Serializable
, usa latransient
parola chiave se mescoli speciali variabili istanziate nella classe (gli oggetti transitori non sono serializzati) e semplicemente usaObjectOutputStream
per scrivere su file eObjectInputStream
leggere da file . Questo è tutto.
[field: NonSerialized]
Se stai scrivendo il tuo codice, diciamo in C ++, puoi usare file binari. I file binari ti danno una forma di crittografia attraverso l'offuscamento. Ma come documentato in tutti gli Internet, questa è una forma molto debole di sicurezza.
O, puoi usare qualcosa come RapidXML se vuoi una soluzione leggibile dall'uomo.
Se stai usando un qualche tipo di framework, guarda le sue funzioni di supporto ai file. HTH
La maggior parte dei giochi che ho visto usa solo codice scritto a mano per leggere / scrivere da file binari. Spesso, il formato su disco sarà una replica esatta del layout di memoria di un oggetto, quindi il caricamento è solo:
È veloce, ma è un lavoro ingrato da mantenere, specifico per la piattaforma e poco flessibile.
Ultimamente, ho visto un paio di giochi usare SQLite. Alla gente con cui ho parlato sembra piacere.
La serializzazione è menzionata in alcune delle altre risposte e sono d'accordo che sia una soluzione ragionevole. Un modo in cui fallisce è il controllo delle versioni.
Supponiamo che tu rilasci il tuo gioco e che la gente lo giochi e crei alcuni salvataggi. Quindi in una patch successiva si desidera correggere un bug o aggiungere alcune funzionalità. Se usi un semplice metodo di serializzazione binaria e aggiungi un membro alle tue classi, la serializzazione potrebbe non essere compatibile con i vecchi giochi di salvataggio quando i clienti installano la tua patch.
Quindi, qualunque sia l'approccio che usi, assicurati di pensare a questo problema prima di rilasciare il gioco la prima volta! I clienti non saranno felici se dovranno ricominciare da capo dopo aver applicato una patch.
Un modo per evitarlo è che ogni tipo di dati di base implementi i metodi Salva (versione) e Carica (versione) che siano abbastanza intelligenti da sapere quali dati salvare e caricare per ogni versione del gioco. In questo modo puoi supportare la retrocompatibilità dei tuoi salvataggi e fallire con grazia se un utente prova a caricare un salvataggi da una versione più recente di quella in esecuzione.
Se puoi usare lo stesso formato che usi per memorizzare i tuoi livelli, è un bonus.
Ad esempio, un gioco come Peggle potrebbe avere una disposizione iniziale della tavola, il numero di palline, il punteggio attuale (0 per la tavola iniziale), ecc. Quindi una partita salvata può usare esattamente lo stesso formato.
Se usi lo stesso formato, il gioco di salvataggio e il caricamento del livello possono condividere il codice rendendo il tuo lavoro più semplice!
Per un gioco con file di mappe molto grandi, il gioco di salvataggio può includere il file di mappa come riferimento. I file di livello iniziale potrebbero anche fare la stessa cosa, il che rende anche più facile il ritorno su quella mappa se per qualche motivo la storia ha il personaggio tornato nello stesso posto, tranne per il fatto che alcuni degli NPC sono morti e ci sono corpi morti che giacciono tutti al di sopra di.