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 .