Come scegliere come archiviare i dati?


25

Dai un pesce a un uomo e gli dai da mangiare per un giorno. Insegna a un uomo a pescare e lo nutri per tutta la vita. - Proverbio cinese

Potrei chiedere quale tipo di archiviazione dei dati dovrei usare per il mio progetto reale, ma voglio imparare a pescare , quindi non ho bisogno di chiedere un pesce ogni volta che inizio un nuovo progetto.

Quindi, fino a quando non ho usato due metodi per archiviare i dati sul mio progetto non di gioco: file XML e database relazionali. So che esiste anche un altro tipo di database, di tipo NoSQL . Tuttavia non saprei se c'è più scelta disponibile per me, o come scegliere in primo luogo, a parte la scelta arbitraria.

Quindi la domanda è la seguente: come devo scegliere il tipo di archiviazione dei dati per un progetto di gioco?

E sarei interessato al seguente criterio nella scelta:

  • La dimensione del progetto.
  • La piattaforma di destinazione del gioco, nonché la piattaforma di sviluppo utilizzata.
  • La complessità della struttura dei dati.
  • Aggiunta portabilità dei dati tra molti progetti.
  • Aggiunto2 Uso silenzioso dei dati tra diversi progetti. (es. dati utente)
  • Aggiunto Con quale frequenza è necessario accedere ai dati
  • Aggiunti più tipi di dati per una stessa applicazione
  • Aggiunta 2 Configurazione con archiviazione di più dati.
  • Qualsiasi altro punto che ritieni interessante quando decidi cosa usare.

EDIT So di Sarebbe meglio usare XML / JSON / Text o un database per archiviare contenuti di gioco? , ma ho pensato che non rispondesse esattamente al mio punto. Ora, se sbaglio, sarei felice di mostrarmi l'errore nei miei modi.

EDIT2 Aggiunti alcuni altri punti che riterrei rilevanti. Inoltre, sarei interessato a sapere quali altre opzioni sono disponibili, a parte l'archiviazione di file flat e il database relazionale. Che dire del database non relazionale, per esempio? Quando è rilevante utilizzare un database di questo tipo rispetto alle altre opzioni precedentemente menzionate?


Vorrei sapere perché ho un voto negativo? La mia domanda è troppo ampia? fuori tema? Sono necessarie ulteriori informazioni?
Eldros,

Non sono il downvoter. Ma per favore, questo è stato discusso molte volte. Che ne dici di provare il campo di ricerca? Mi ha portato a questo: gamedev.stackexchange.com/questions/4666/…
Notabene,

1
@notabene: sapevo di questa discussione e in qualche modo pensavo che la portata della mia domanda fosse diversa da questa. Stava cercando una risposta per un gioco basato su componenti (qualunque esso sia, ma suppongo che ci siano altri tipi di giochi là fuori), e aveva già ridotto la scelta in un certo senso, e quasi ogni risposta gestiva un tipo di tecnologia. D'altra parte sto chiedendo una metodologia di base su come scegliere e vorrei avere più di un confronto. Ora, se la community lo considera ancora come un duplicato, prenderò in considerazione la possibilità di eliminare questa domanda e cercherò di ottenere la mia risposta sull'altro thread.
Eldros,

Altrimenti, vorrei sapere cosa devo cambiare per chiarire che è un'altra domanda.
Eldros,

@notabene: Ad esempio, sono sicuro che esiste uno scenario in cui non viene utilizzato un archivio dati esterno, ma i dati verrebbero memorizzati nel "codice" .
Eldros,

Risposte:


21

La tua domanda è davvero ampia a causa del gran numero di generi là fuori, ma ecco la prospettiva di uno sviluppatore di software professionale.

Hai fornito un elenco di criteri che desideri utilizzare per determinare quale meccanismo di persistenza dei dati usi. Quelli erano:

  • La dimensione del progetto.
  • La piattaforma designata dal gioco.
  • La complessità della struttura dei dati.
  • Portabilità dei dati tra molti progetti.
  • Con quale frequenza è necessario accedere ai dati
  • Più tipi di dati per una stessa applicazione
  • Qualsiasi altro punto che ritieni interessante quando decidi cosa usare.

Innanzitutto dobbiamo stabilire quali opzioni sono disponibili per noi. Dal momento che non hai specificato un linguaggio o una tecnologia, è difficile dirlo con esattezza, ma probabilmente stai cercando di decidere tra l' archiviazione di database XML e relazionale .

Una distinzione importante da fare è che XML non è in realtà un meccanismo di archiviazione tanto quanto una tecnica di serializzazione. È un modo per rappresentare strutture in memoria per il tuo gioco. Detto questo, stai davvero parlando di archiviazione di file flat vs. database relazionale . Queste non sono le uniche opzioni, ma sono le più comuni, quindi le userò.

Per file flat:

  • XML
  • JSON
  • YAML
  • XAML
  • Testo semplice

Per i database:

  • server SQL
  • MySQL
  • DB2
  • Oracolo
  • Molti altri

EDIT: Hai chiesto informazioni su altri tipi di meccanismi oltre a file e database relazionali. L'unico altro notevole tipo di database che ho visto usato regolarmente sono i database "in stile Berkeley", che sono essenzialmente basati su valori-chiave. Questi tendono a usare gli alberi B per strutturare i dati in modo che le ricerche siano veloci. Questi sono ottimi per la ricerca di configurazione / impostazione in cui sai esattamente cosa vuoi (ad esempio, dammi tutti i dati di telemetria per "Livello 1").

Ora che abbiamo tutti i concetti di base, tocchiamo alcuni dei tuoi criteri.

La dimensione del progetto.

Alcuni potrebbero non essere d'accordo, ma le dimensioni del progetto non avranno necessariamente un impatto enorme sul meccanismo di persistenza dei dati. Dovrai creare una libreria riutilizzabile di funzioni che memorizzano / caricano i dati da qualsiasi meccanismo tu voglia. Suggerirei anche di implementare un livello di astrazione (controlla il modello dell'adattatore ) in modo da poter facilmente modificare il meccanismo di persistenza, se necessario.

Detto questo, per i piccoli progetti, l'utilizzo dell'XML sul file system può potenzialmente funzionare bene, ma ti consigliamo di affrontare alcuni dei tuoi problemi di sicurezza (ad esempio, la crittografia) in modo che i giocatori non possano modificare i dati a piacimento.

La piattaforma designata dal gioco.

La piattaforma non sarà nemmeno un grosso problema. Dovresti essere più preoccupato per la tua piattaforma di sviluppo che per quella di destinazione. La ragione di ciò è che alcune lingue gestiscono alcuni tipi di markup o database meglio di altri. Ciò non significa che non si possa usare nessuno dei precedenti in quasi tutte le lingue, ma a volte è meglio usare gli strumenti supportati disponibili. Qualsiasi piattaforma supporterà file flat e analizzerà XML, ma su piattaforme mobili potresti voler considerare la serializzazione binaria, se possibile, o almeno ottimizzare il tuo XML per l'archiviazione.

La complessità della struttura dei dati.

È un po 'complicato. I database relazionali sono perfetti solo per questo ... archiviare entità e le loro relazioni. Hai una migliore capacità di imporre la struttura utilizzando un repository di archiviazione relazionale rispetto ai file su un file system. Considera i tipi di relazioni tra le tue entità e la frequenza con cui le cambi o trovi entità correlate. Per strutture estremamente complesse, suggerirei di seguire il percorso del database.

Portabilità dei dati tra molti progetti.

Quando si tratta di portabilità, è necessario considerare il fatto che i database sono naturalmente più pesanti dei file. C'è un overhead di installazione e configurazione, saranno disponibili database diversi per piattaforme diverse, ecc. SQLite è un ottimo modo per aggirare questo. Tuttavia, quando si tratta di portabilità, probabilmente avrai un tempo più facile con soluzioni basate su file come XML.

EDIT: ci sono alcune altre preoccupazioni che hai menzionato sulla portabilità in uno dei tuoi commenti. In definitiva, non si desidera che i dati vengano associati troppo strettamente a nessun prodotto o tipo di file. In definitiva, è meglio se è possibile archiviare i dati di magazzino (livelli, nemici, ecc.) In una sorta di formato astratto (file delimitati da tabulazioni, XML, ecc.) Che è possibile analizzare e archiviare facilmente in un database / file system durante la compilazione o il caricamento tempo. Ciò significa che puoi scambiare il tuo meccanismo di archiviazione per un capriccio e riscrivere il pezzo di analisi.

Con quale frequenza è necessario accedere ai dati

Un sacco di accesso ai dati significa un sacco di I / O a meno che non si disponga di un meccanismo di memorizzazione nella cache. I database mantengono le strutture in memoria e sono ideali per la manipolazione e il recupero dei dati. Se i dati persistono davvero costantemente, potresti voler rimanere con un database.

Più tipi di dati per una stessa applicazione

Il volume è certamente una considerazione, ma a meno che non si parli di persistere di migliaia o milioni di oggetti, il file system sarà comunque accettabile come soluzione.

Tipo di gioco

Il tipo di gioco che stai costruendo può avere un'enorme influenza sulla piattaforma che scegli. Sì, per la maggior parte dei giochi single-player solo per client, starai bene usando una soluzione basata su file system compressa o crittografata. Se stai parlando di giochi con un componente online, sarebbe folle. Vai sul percorso del database e risparmia il mal di testa. Consenti al server di gestire tutti i tuoi dati utilizzando un cluster back-end.

Spero che alcuni di questi feedback siano d'aiuto. Non è assolutamente completo e prendere la decisione dipende da te, ma il mio commento dovrebbe darti alcune cose a cui pensare.

MODIFICARE: Ci sono alcune volte in cui assumere un approccio hybdrid ha molto senso. Ad esempio, supponiamo che tu stia sviluppando un MMORPG. Sul lato client, è possibile archiviare i dati memorizzati nella cache su altri giocatori in un database non relazionale (come menzionato sopra). Sul lato server, stai memorizzando tutti i dati di gioco in un database relazionale per persistere. E poi di nuovo sul lato client probabilmente stai memorizzando i dati di registro, i dati di configurazione, ecc. In file XML / flat per una più facile accessibilità.

Un altro poster ha anche detto che a volte è bello, anche se si stanno archiviando dati per la produzione in un database, avere un modo in cui è possibile utilizzare file flat per lo sviluppo ... può essere più semplice rimuovere un altro prodotto dal mix .


+1 Ottima risposta, e ho già imparato molto da esso. Ecco perché odio farlo, ma ci sono alcuni punti che non sono stati affrontati correttamente. e questo è molto probabilmente perché non sono riuscito a esprimerli in modo adeguato. 1) Punto minore, ma quando parlavo di piattaforma, in effetti parlavo di piattaforma di sviluppo. Ma hai comunque affrontato questo punto. 2) Per portabilità intendevo riutilizzabilità, ma il tuo punto sulla portabilità era in realtà un punto che non avevo considerato, ma si è rivelato abbastanza rilevante. (-> continua)
Eldros,

3) Quando si affrontano i diversi tipi di dati per la stessa applicazione, non si è parlato di utilizzare una combinazione di archiviazione dei dati, ognuno con il proprio compito. Ma credo che dovrò considerare separatamente il ruolo di ogni tipo di dati. 4) Ho sentito che esiste un altro tipo di archiviazione dei dati oltre al file flat e al database relazionale, anch'io vorrei conoscerli, come indicato nel PO. Ora modificherò il PO di conseguenza, per riflettere ciò che ho detto in quei commenti.
Eldros,

Aggiornato..hope questo risponde alle tue domande. :)
Ed Altorfer,

1

Ultimamente mi sono trovato vincolato dalla rigidità / difficoltà di aggiunta ai database relazionali. Mi piacerebbe esplorare database basati su documenti (ad esempio couchdb), poiché sembrano molto adatti a giochi, stato e flessibilità. Ma non è davvero pratico impostare più tipi di database per un piccolo progetto. Di conseguenza, ho impostato un hack simile al semplice utilizzo di un campo BLOB binario in alcuni campi del database.

Quello che sto facendo è usare i dati con codifica json nel database e un wrapper che converte i dati in json ed esegui il backout ogni volta che è necessario. Quindi un profilo del personaggio di base potrebbe apparire così nel database:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json è ancora ben leggibile nel database, quindi se stai lavorando senza problemi con sql e a volte accedi direttamente al database, è modificabile manualmente se lo desideri.

Ora, tutto ciò è un hack e non consiglio di copiarlo, ma ecco il punto generale: non fare affidamento solo su un sistema. Utilizzare un database relazionale e modificare il sistema. Oppure utilizza due diversi tipi di sistemi di archiviazione dei dati (ad esempio file flat e database relazionale?), In modo da ottenere il massimo beneficio da entrambi. Indipendentemente da ciò che le persone suggeriscono o da quale sistema utilizzi, lungo la linea troverai circostanze in cui un altro approccio potrebbe funzionare meglio, quindi preparati ad aggiungere un'alternativa e vedere dove ti porta.


0

Nel gene RTS, i dati di gioco sono stati archiviati in file.

Le unità e gli attributi sono stati archiviati in file INI o XML o altri formati basati su testo e i modelli sono stati un mix di formati binari o persino basati su testo, nonché le trame, i suoni e altri media in formati tradizionali. A volte è stato in un contenitore con crittografia grezza - mi viene in mente il formato mix di Westwood. Ma questa è per lo più offuscata: se ci guardi dentro, sono solo normali file in formati facili da gestire.

Con l'avvento del gioco online è diventato sempre più comune il provisioning dei dati di gioco post-installazione su Internet, anche se spesso questi sono ancora memorizzati nel filesystem.


Questo non è il caso della "guerra dell'IA" (sito web down atm). Utilizza un database relazionale affinché l'IA sia in grado di eseguire query Linq quando decide il comportamento.
Nailer

0

Perché utilizzare un metodo di archiviazione dei dati?

Nella maggior parte dei casi, il gioco che rilasci nel mondo non richiede le stesse funzionalità di archiviazione dei dati di cui il gioco ha bisogno durante lo sviluppo.

Ecco un confronto di alcuni requisiti di rilascio / sviluppo: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

Idealmente, definiresti un'interfaccia per il tuo modulo di caricamento dei dati e quindi crei più versioni, ognuna su misura per esigenze specifiche.

Su un progetto su cui ho lavorato molti anni fa, il caricamento dei dati di livello dal CD richiedeva troppo tempo (anche l'HD non era eccezionale). Quindi ho pensato a quanto segue. Avevo tre metodi per caricare i dati di livello: -

  1. Caricamento normale - per i tempi di sviluppo in cui le risorse stavano cambiando
  2. Pre-release: efficacemente un metodo per convertire i dati normali in dati a caricamento rapido
  3. Rilascio: solo dati veloci (non modificabili)

Ciò ha ridotto i tempi di caricamento da minuti a secondi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.