Sarebbe meglio usare XML / JSON / Text o un database per archiviare i contenuti di gioco?

Sto pensando a come implementare un gioco basato su componenti, poiché sembra essere la cosa più interessante e mi piace l'idea di un design così flessibile. Una delle caratteristiche di tale progetto è che l'aggiunta di nuove cose al gioco può essere fatta attraverso i dati, spesso presentati come caricamento di contenuti tramite file di testo come XML. Questo ha il vantaggio di essere leggibile e facilmente modificabile in qualsiasi editor di testo. Il rovescio della medaglia, il testo può essere più lento da gestire e devi gestire una grande raccolta di file di dati. Formati simili basati su testo come file JSON o di configurazione avrebbero vantaggi simili.

Dall'altro lato, ci sono piccoli database portatili come SQLite o Tokyo Cabinet. Sebbene non siano leggibili direttamente dall'uomo, questi file sono facili da interfacciare e immagino che sarebbe comunque preferibile un qualche tipo di strumento di modifica per la progettazione dei contenuti di gioco. L'uso di un DB consente una memorizzazione coerente delle informazioni di configurazione e un facile recupero. È possibile serializzare i dati in un DB anche per salvare i giochi.

Per quanto riguarda le prestazioni, penso che in genere XML sia più veloce per file di piccole dimensioni, ma un database si adatta meglio a grandi quantità di dati. Immagino che qualsiasi gioco reale avrà un sacco di oggetti di gioco.

Quindi la domanda: qual è l'approccio preferibile? Mi sto inclinando verso il DB, ma voglio sapere se ci sono insidie ​​nascoste o vantaggi reali per i file di testo. O se ci sono altre alternative oltre a queste (serializzare in formato binario immagino?)

Potrebbe non venire così tanto per un piccolo gioco personale, ma un problema difficile quando si tratta di dati di gioco è l'editing / versioning multiutente. Usiamo molti piccoli file di testo che vengono elaborati in un piccolo numero di BLOB binari da un processo di compilazione. Ciò semplifica la vita dei progettisti poiché hanno molta flessibilità nel loro flusso di lavoro. CCP, come contro esempio, utilizza un database di modifica centrale a cui si connettono tutti i progettisti. Questo rende la fase di compilazione non necessaria (o almeno molto più semplice) ma significa che devi implementare tu stesso tutte le funzionalità di controllo delle versioni e del flusso di lavoro, quindi sono destinati a essere più semplici di altri strumenti. Puoi gestire le prestazioni in entrambi i casi, quindi la vera domanda è cosa desideri per un flusso di lavoro di progettazione e come puoi arrivarci?

JSON è molto leggero e di facile comprensione. Penso che sia più adatto per un gioco. cJSON è davvero carino. si integrerà anche nel tuo sorgente allo stesso modo di SQLlite.

I file XML sono più difficili da modificare per gli utenti di quanto si pensi. se segui questa strada potresti voler creare un editor che la gente possa usare per aiutarli a evitare insidie ​​comuni.

Sono in ritardo alla festa qui, ma ho trascorso MOLTO tempo a ricercare questo.

Innanzitutto perché non utilizzo quanto segue:

XML: eccessivamente dettagliato. Tonnellate di ridondanza. Ripetendo i nomi dei campi? SCHIFOSO

JSON: Penso che JSON sia ottimo per un layout dell'interfaccia utente ma per un database, diavolo no. Avrà gli stessi problemi di XML, ridondanza e annidamento profondo. SCHIFOSO.

SQL : questa è un'ottima opzione, se gestisci il mal di testa della sua configurazione. Ho realizzato giochi per dispositivi mobili in cui archiviamo i dati di gioco online in un database SQL. Il formato della tabella è carino. Il problema era che dovevamo recuperare il database online e impostare che può essere una seccatura. Ma SQL è una soluzione decente. Unity non lo supporta in modo nativo e i plugin che ho provato avevano grossi problemi (specialmente quando cercavo di farlo funzionare con il controllo della versione).

Infine, ecco la soluzione che ho scelto di utilizzare (e lo adoro).

CSV : semplice. Mi consente di utilizzare il formato tabella e ho un semplice punto di riferimento quando devo aggiornarlo. Posso avere un tavolo per tutte le mie armi, colonne per tutti gli attributi e file per ogni tipo di arma.

Puoi usare Microsoft Excel ma sputa questi stupidi avvisi ogni volta che devi salvare. Puoi usare le macro per sovrascriverlo, ma dico di salvarti il ​​problema e ottenere LibreOffice . È gratuito, supporta l'editing CSV e quando apri il file carica la larghezza della colonna in modo che corrisponda al nome (Excel non lo fa e mi ha fatto impazzire).

Quindi devi solo analizzare i file CSV nel tuo gioco. Uso Unity, quindi tutto quello che dovevo fare era usare questo parser CSV C # elegante che ho trovato:

Esempio di parser CSV

Converti i file CSV nei tuoi oggetti dati di gioco e sei a posto. Con Unity puoi trasformarli in ScriptableObjects . Quindi il mio flusso di lavoro è: Aggiorna CSV -> Analizza CSV in Scriptable Objects -> Usa i dati da ScriptableObjects per il mio gioco

La risposta a questo dipende dalla lingua che stai usando per il gioco.

Se si utilizza C ++, si consiglia di utilizzare una delle librerie XML esistenti (come TinyXml o eXpat ).

D'altra parte, se si utilizza PHP, è possibile utilizzare facilmente un server di database come MySQL o SQLite. (Tieni presente che se segui questa strada, avrai bisogno di più risorse perché il server di database verrà eseguito come processo separato e le applicazioni di database più grandi come MySQL possono consumare molta RAM durante l'esecuzione.)

JSON sta guadagnando molto slancio ed è sicuramente la scelta migliore se la tua applicazione è scritta usando più di una lingua.

In breve, dipende da cosa è facilmente utilizzabile nella tua lingua.

Se si desidera rimanere nel regno XML delle cose, è possibile utilizzare XML binario per aumentare le prestazioni del carico.

Ad esempio Fast Infoset è un'implementazione di xml binario

Si può pensare a Fast Infoset come gzip per XML, sebbene FI abbia l'obiettivo di ottimizzare sia le dimensioni del documento che le prestazioni di elaborazione, mentre gzip ottimizza solo le dimensioni. Mentre la formattazione originale viene persa, nessuna informazione viene persa nella conversione da XML a FI e viceversa.

Ho progettato database e ho giocato con molte idee di gioco per anni. Il mio preferito personale al momento, è un po 'un formato basato su testo, leggibile dall'uomo per le configurazioni, ma poi analizza questi "script lenti" in qualcosa di più eseguibile. Proprio come JAVA e .NET è compilato in bytecode runtime.

La stessa idea va qui. Ho una versione "sorgente" dei componenti e quindi un pre-compilatore / parser li attraversa. Se occupano troppa memoria, è possibile inserirli in una base di dati SQL veloce di qualche tipo o salvarli come file binari. Ma il mio punto è, utilizzare la memoria o il database SQL come area di lavoro / cache in modo da non dover analizzare gli script più e più volte. Potresti creare il compilatore, spostare i file analizzati in un "source-lib" e in questo modo lasciare che anche il precompilatore esegua il controllo delle versioni (mantenendo i file precedenti a scopo di rollback).

Se si tratta di "spazio su disco rigido illimitato", quindi iscriviti a qualcosa come Dropbox o Amazon S3 e sincronizza con loro.

Quindi il piano per me è attualmente:

1. Config / scripts / xml (alcuni formati leggibili dall'uomo) come file di testo (proprio come il codice sorgente)
2. Analizzatore / validatore che esegue nuovi script e verifica che stiano seguendo le regole
3. Compilatore che rende binario o SQL-row i file originali, in modo che questi siano veloci da recuperare + veloci da eseguire.

Per quanto riguarda la stabilità, al momento sto costruendo il database per essere "co-location ospitato" e autosincronizzare anche tra più posizioni, in modo che se si verifica un errore di rete / hardware in una posizione, gli altri siti dovrebbero essere in grado di gestire lo stesso traffico / gamestates.

Se usi couchdb essenzialmente salverai tutto come una struttura JSON. Couchdb si occuperà di replicare i dati (multipli) dell'utente in modo più o meno indolore.

Puoi trovare una procedura in Unity Wiki con PHP, MySQL e C # / JavaScript e funziona benissimo per il suo scopo.

Si compone di tre passaggi

1. Crea un database MySQL vuoto e una tabella.
2. Crea uno script lato server PHP (Questo si connetterà alla tabella MySQL, riceverà i dati da uno script Unity (passaggio 3) e interrogherà il database (gli esempi forniti sono l'inserimento o la selezione dei dati))
3. Crea lo script Unity Controller (questo si connetterà allo script PHP creato nel passaggio 2)