2009-05-09 12 views
12

Non vedo una risposta a questa domanda qui su SO, il che mi fa temere che sia incredibilmente semplice e mi manca solo qualcosa, ma qui va.In che modo i giochi gestiscono i contenuti salvati?

Sfondo, sentitevi liberi di saltare: ho bisogno di un corso unico per la mia laurea che ho saltato fuori anni fa. In teoria è Computer Graphics, ma da quando ho lasciato è diventato più sviluppo di giochi. E questo è fantastico perché per me è più interessante degli algoritmi di riempimento e delle traduzioni e quant'altro fosse un tempo. È un corso di 4 anni offerto solo ogni due anni, ma sono riuscito a convincere il dipartimento a farmi fare uno studio indipendente del 4 ° anno sullo stesso argomento e chiamarlo abbastanza buono.

Il prof "che gestisce" lo studio indipendente non insegna l'attuale corso di Computer Graphics, quindi mentre è un ragazzo intelligente questo non è proprio il suo campo. Quindi la maggior parte delle mie domande sono lasciate a me, un libro di testo e Internet. Sai ... come dovrebbe essere uno studio indipendente. :)

/Background

Ho un compagno che ama di sviluppare sistemi di gioco per divertimento. Ho intenzione di prendere uno dei suoi giochi da tavolo e renderlo un gioco per computer che utilizza XNA.

Non prevedo alcuna sfida insormontabile con le meccaniche di gioco, ma una cosa che mi incuriosisce è come la maggior parte dei giochi salva il loro contenuto? Intendo questo in un paio di modi e spero di poterli esprimere chiaramente.

Prendi il caso di qualsiasi gioco di ruolo che tu abbia mai giocato. Puoi premere il pulsante "Salva" e salvare il mondo, le informazioni del tuo personaggio e qualsiasi altra informazione necessaria. Successivamente, puoi premere il pulsante "Carica" ​​e riportarlo indietro.

Oppure il caso del dialogo NPC. Quando mi imbatto nel Merchant # 853, sputa a caso uno dei 3 diversi saluti.

Ce ne sono altri che posso pensare ma sono davvero solo variazioni sullo stesso tema. Anche con questi due esempi mi sembra che si possa usare la stessa meccanica, ma cos'è quella meccanica?

Ho fatto sviluppo web per anni quindi la mia mente salta automaticamente a "database!". Un database è la soluzione a qualsiasi problema. E posso vedere come potrebbe funzionare qui, ma l'overhead sembra piuttosto ripido. "Ecco il mio gioco compilato 6mb ... oh e l'installazione di MySQL 68mb." O ancora peggio visto che sto usando XNA, forse avrei bisogno di trovare un modo per raggruppare SQL Server. :)

Ho pensato forse XML ma non mi sembra giusto. Come funzionerebbe se volessi correre su Xbox? O Zune? (Non sono necessari per quello che sto facendo, ma ci deve essere una soluzione da qualche parte che li tenga in considerazione.)

Qualcuno conosce il segreto? O hai qualche idea comunque?

Grazie Jeff

risposta

6

Un approccio è quello di utilizzare NET serializzazione.

Assicurarsi che lo stato del gioco sia un grafico completamente connesso e che ogni classe in tale grafico sia contrassegnata come Serializable (con SerializableAttribute), per il salvataggio (e il caricamento) è possibile utilizzare la normale serializzazione .net.

È possibile guardare il codice di base per Project Xenocide (gioco XNA open source) per vedere come è stato fatto lì.

+0

Grazie Oddio, scaverò attraverso quello – JeffMc

+0

Ti suggerisco di dare un'occhiata alla schermata di salvataggio del gioco e vedere cosa succede che cosa risparmio come punto di partenza. – Oded

+0

La serializzazione è un buon punto di partenza, ma le cose diventano un po 'confuse perché non si desidera serializzare le risorse come texture, ma quali riferimenti devono essere salvati e ricaricati in modo intelligente. –

0

Mentre il gioco è in esecuzione, proverei a mantenere tutto ciò che si riferisce al contesto corrente in memoria. L'inizializzazione può essere mantenuta in un formato serializzato adatto e letto all'avvio. XML funzionerebbe, ma è un po 'prolisso. Un formato binario compatto personalizzato è probabilmente più appropriato. Lo stesso vale per lo stato salvato. Qualsiasi oggetto debba essere reinizializzato quando il gioco salvato viene caricato deve essere serializzato su un formato binario personalizzato e quindi ricostituito sul carico. Se si verificano problemi di memoria, un piccolo database personalizzato ottimizzato per la velocità sarebbe un'altra alternativa. Potrebbe essere pre-compilato durante l'installazione.

5

È possibile utilizzare un database SQLite, con SQLite.NET wrapper. L'ho usato e l'ho trovato abbastanza semplice. L'intera DLL è solo 850 KB e il database stesso si trova in un singolo file (con i file temporanei creati in base alle esigenze). Quindi i tuoi utenti non dovrebbero avere un problema.

Ma si potrebbe anche utilizzare un semplice file XML o un formato binario sviluppato in proprio. Dipende tutto da come stai interrogando i dati e quanti dati sono coinvolti. Non c'è un'unica risposta.

+0

Questo non funzionerà su XBox o Zune –

+0

Innanzitutto, ha affermato che XBox e Zune non sono necessari. In secondo luogo, SQLite (anche se forse non SQLite.NET) può essere utilizzato con XBox (vedere http://www.mail-archive.com/[email protected]/msg17898.html). Non so per certo su Zune. –

+1

Molti giochi usano SQLite per salvare il loro stato. È anche il mio modo preferito. – gradbot

1

Dalla mia esperienza limitata nello sviluppo di giochi, salvare i giochi in realtà non utilizzare molta memoria. Come diceva tvanfosson, normalmente memorizzi la maggior parte delle cose in memoria durante il gioco, quindi salvare lo stato su disco non è un problema.

Ecco un breve esempio. Supponendo un RPG a persona singola, se avessi bisogno solo di salvare la posizione del tuo personaggio, avresti forse un numero di livello, coordinate xyz e forse la direzione che stai affrontando. Sono solo pochi byte.

Supponiamo ora che sia necessario salvare lo stato/posizione di oggetti come pacchetti di salute, casse, nemici, salute del personaggio e oggetti prelevati, ecc. Potresti avere poche centinaia di questi al massimo, che sarebbero facilmente inferiori a 10 KB. .

Ovviamente le cose possono diventare molto complicate con giochi più complessi. Il trucco è archiviare solo ciò che è veramente necessario per ricreare l'esperienza del giocatore. Un sacco di giochi ti permettono solo di risparmiare in determinati posti, come la fine di un livello. In questo caso è sufficiente memorizzare il nuovo numero di livello più il risultato dei livelli precedenti (ad esempio, rimanendo in salute, articoli prelevati).

Anche se si consentono punti di salvataggio arbitrari, è possibile ignorare lo stato di qualsiasi posizione/livello a cui non è possibile tornare. E probabilmente non vorresti che l'utente fosse in grado di salvare il mid-jump.

MODIFICA: per quanto riguarda il formato del file ... utilizzare il metodo più conveniente per il tipo di dati! XML è un bel modo di fare le cose. Non è sicuro quanto sarebbe efficace un database dato che per un RPG ogni frammento di dati può essere molto diverso; Potresti finire con un mucchio di tavoli con una fila ciascuno.

La maggior parte dei giochi utilizza i propri formati di file binari. In primo luogo ciò riduce drasticamente la quantità di memoria. In secondo luogo, aiuta a prevenire l'imbroglio degli utenti modificando manualmente il salvataggio del gioco - se hai XML come <health value="10"/> è molto facile modificare il file per leggere <health value="100"/>. Il lato negativo del binario è che è molto più difficile per il debug.

+1

Penso che i salvataggi di Fallout 3 siano come 3mb ... che è il più grande che abbia mai visto. Ma conservano * tutto *. Ogni persona che uccidi e ogni oggetto che lasci mai siederà lì per sempre. In altri giochi, i corpi scompaiono entro 10 secondi ... follia! Ma fuori tema: D – mpen

+0

Non puoi davvero generalizzare la dimensione del gioco di salvataggio essendo piccola. Come menziona @Mark, giochi come Fallout 3 (e Oblivion, in esecuzione sullo stesso motore) fanno davvero risparmiare un sacco di cose. Diventa quindi fondamentale che il motore utilizzi un efficiente meccanismo di archiviazione. –

+0

Ma se 3MB è "molto" per un gioco, questo è abbastanza buono perché 3MB non è proprio molto spazio, sia in memoria che su disco. Le cache del browser Web sono almeno 10 volte questa dimensione. Come ho detto, se implementi regole come non essere in grado di tornare ai livelli precedenti, riduci il tuo spazio al prossimo-nulla. – DisgruntledGoat

2

Come altri hanno notato, la serializzazione è la strada da percorrere. E Gamasutra ha appena pubblicato un articolo su data baking.

+0

Grazie, esaminerò l'articolo. – JeffMc

+0

Sicuramente non penso che la serializzazione automatica sia l'unica strada da percorrere. Ciò limita fortemente il framework .NET (cosa succederebbe se si volesse portarlo in un secondo momento in seguito?), E ti dà meno controllo sul tuo formato. Inoltre, tende a includere alcuni dati ridondanti. –

+0

@Matthew: se stai parlando di un formato di dati intercambiabile tra piattaforme, allora è più difficile. Ma se questo è un problema, quindi l'utilizzo di .NET stesso potrebbe non essere l'idea migliore. –

8

Ci sono due modi principali di salvare i giochi, uno semplice e uno complesso. Il primo modo è quello di memorizzare semplicemente il livello corrente, il punteggio corrente e una manciata di altre statistiche. Questo è visto in giochi come Super Mario Galaxy e la maggior parte dei precedenti giochi basati su moduli console. Il salvataggio del gioco non ripristina la tua posizione esatta, ma solo i livelli che hai completato.Questi giochi di salvataggio sono in genere molto semplici e richiedono pochissima memoria.

Il secondo modo non solo memorizza i tuoi progressi generali, ma memorizza ogni piccolo dettaglio, come le posizioni nemiche, il loro attuale fotogramma di animazione e così via, in modo che il caricamento di un salvataggio ti metta nel punto esatto in cui fermato, con tutti i nemici a posto, invece di tornare all'inizio di un livello. Questi salvataggi tendono ad essere molto più grandi rispetto all'altra versione e quindi sono visti principalmente sui giochi per PC.

I database non vengono utilizzati in nessuno di questi schemi, poiché lo scopo dei database è di fornire la possibilità di interrogare dinamicamente le strutture di dati, ma non è un modo per interrogare i singoli pezzi, ma solo un modo per staticamente memorizzali. Quando viene caricato un savegame, viene caricato completamente nella memoria e da lì sul motore del gioco fa il suo gioco con i dati. Esistono alcune eccezioni, come i MMORPG che potrebbero funzionare su un database, ma generalmente i giochi per giocatore singolo no.

Il modo in cui i dati vengono effettivamente memorizzati dipende dal gioco. I più comuni sembrano essere semplici formati di dati binari, in quanto sono molto meglio in termini di spazio su disco rispetto all'XML. Nei vecchi giochi quei formati binari dove spesso si verificavano dump raw di una parte di memoria dei processi, quindi non avevano una struttura ben ponderata e spesso si rompevano quando veniva rilasciata una patch o una versione diversa di un gioco, in qualche moderno i giochi è ancora il caso. Anche XML può essere usato così come qualsiasi altro formato di file basato su testo.

In gran parte questo è più un problema di progettazione di un gioco che di programmazione, poiché il modo in cui un gioco può essere salvato può cambiare drasticamente il suo modo di giocare. Il modo semplice, in cui è sufficiente salvare il numero di livello e alcune statistiche, è tuttavia molto più semplice da implementare, in quanto si tratta di poche righe di codice. Mentre il secondo richiede la serializzazione della maggior parte delle tue classi, che per un gioco complesso può essere un problema piuttosto complicato e portare a molti bug sottili.

Problemi correlati