Qual è un buon formato di file per il salvataggio dei dati di gioco? [chiuso]

Devo salvare alcuni dati di gioco personalizzati. Mappa, giocatore, ecc.

Tutti avranno "oggetti secondari". Ad esempio, una mappa e una mappa avranno un "array" di tessere. cioè, dati gerarchici. Eventualmente niente binario.

Quale sarebbe un buon formato per questi?

Finora ho considerato:

Serailization: questo è VELOCE e facile, ma tende a rompersi quando cambio le classi sottostanti :(

XML: odio davvero analizzare questo. Il mio caso di test era composto da oltre 100 righe di codice e sembrava tonnellate di "lavoro intenso" anche per un formato molto semplice.

INI: sarebbe davvero maldestra per i dati gerarchici.

Protobuf: non l' hai mai usato, ma leggi che devi fare un sacco di schivate e rotture manuali se cambi classe.

Altre opzioni? È per questo che sono qui!

Modifica: questo è Java btw.

Modifica 2:

Ho optato per la "serializzazione binaria controllata" (vedi sotto).

Professionisti:

• è veloce

• è piccolo (su disco) e può essere facilmente compresso / decompresso durante la lettura / scrittura.

• è super facile da leggere / scrivere dal gioco e dal set di strumenti.

• Posso decidere cosa includere / escludere l'oggetto.

• Oggetti / dati possono essere nidificati.

Contro:

• Impossibile modificarlo manualmente (come XML, YAML, ecc.)

• Non è possibile leggerlo / modificarlo facilmente con gli script

• La serializzazione Java per impostazione predefinita è piuttosto lenta / gonfia rispetto ad altre impianti, ma è stabile e funziona

Per visualizzare dati gerarchici, YAML o JSON sarebbero buone opzioni. Sono molto più semplici e più facili da analizzare rispetto a XML.

Un'altra opzione sarebbe un processo di serializzazione binaria "controllato". Ogni oggetto scrive il suo stato in modo controllato, cioè

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

id Tech 4 (motore di Quake 4 / Doom 3) utilizza tale approccio.

Un formato binario ben fatto ha davvero tutti i vantaggi, è veloce, ragionevolmente piccolo e flessibile come lo fai tu.

Fare un formato binario non è vincolato da nessuna regola, il che è un grande vantaggio, ma ironicamente è in gran parte ciò che ha dato una cattiva reputazione alle strutture di file binari. XML, JSON e simili prendono molte decisioni per te, sono lungi dall'essere sempre ottimali, ma sono scelte ragionevolmente sicure che di solito ti aiuteranno a evitare alcuni problemi altrimenti comuni.

Identifica questi problemi, progetta il tuo formato tenendo presente questi aspetti e puoi creare un ottimo formato binario.

Se non sei abbastanza esperto / abbastanza sicuro da creare un formato binario e la quantità di dati è abbastanza piccola da avere un impatto sulla velocità trascurabile, ti suggerisco di usare JSON, è semplice, ma fa il lavoro.

La scelta del formato del file dipende fortemente dal set di strumenti corrente e dal gioco che si intende creare. Detto questo ...

Il set di strumenti è uno dei fattori più importanti quando si decide un formato di file di gioco. Se crei un formato binario , devi sempre assicurarti di disporre degli strumenti per inserire i dati di gioco. Potrebbe essere semplice come un editor esadecimale o complesso come Unreal Editor.

Suppongo che il vantaggio principale di XML, YAML o di qualsiasi altro file di lingua sia che puoi modificarlo facilmente tramite un editor di testo. E usando uno standard esistente, ti assicura di non poter sbagliare . Ma questo è estremamente noioso quando hai un migliaio di file, il che mi porta al punto successivo.

Gioco. Che tipo di gioco stai realizzando? Perché dico che ciò influirà sul formato del file? Perché, se stai realizzando qualcosa di simile a un bomberman 2D, potresti cavartela con un semplice file di testo come:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

In altre parole, scegli sempre il formato più ovvio per i tuoi dati specifici . I giochi di ruolo sono il genere di gioco più complesso da realizzare. Richiedono molti dati. Ma non significa che devi rispettare un formato specifico , sia esso binario o basato su testo per tutti i dati del gioco.

• Mappe, particelle e altri elementi grafici tendono a utilizzare un formato binario personalizzato. Perché è il modo più semplice per implementarlo . Descrivere testualmente le mappe non è umanamente sano. Generalmente modificato tramite editor di mappe / livelli / particelle.
• Giocatori, oggetti, nemici, abilità e missioni sono statistiche che influenzano l'equilibrio del gioco . Di solito richiedono un sacco di input e modifiche. Mi piace farlo inserendolo in un file XML per facilitarne l'implementazione, ma avendo comunque un editor di oggetti con cui i designer possono giocare. Il meglio di entrambi i mondi .

In genere, si desidera descrivere il testo con un formato di testo e la grafica con un formato binario. Quanto segue dovrebbe darti un esempio:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

Per riassumere, è alla mia più completa raccomandazione che, se possibile, non copiate i vostri dati, a meno che non sia assolutamente necessario . L'utente finale non si preoccupa di quanto sia fantastico il formato, purché il gioco sia giocabile, è tutto ciò che conta.

Saluti, Roy =)

BSON è molto carino. http://bsonspec.org/ . È più facile analizzare quindi JSON e meglio nel contenere dati binari, ma ha comunque una buona struttura. È in qualche modo simile ai buffer di protocollo. Il rovescio della medaglia è che sembra che ci sia molto supporto per gli strumenti al di fuori di mongodb.

EDIT: MsgPack ( http://msgpack.org/ ) è anche simile a BSON e sembra che stia guadagnando più trazione.

Che cosa è successo al tuo formato di dati binari personalizzato? Se hai paura della serializzazione grezza, scrivi il tuo sistema che scrive i campi secondo necessità e li rilegge. Non c'è bisogno di xml, che è davvero eccessivamente ingombrante e complesso per situazioni in cui non è necessaria la trasparenza fornita dal formato. Basta definire un formato di file ben specificato e attenersi ad esso, lasciando forse un po 'di spazio per l'espansione del set di dati in ciascun record riempiendoli con valori null (supponiamo che tu abbia un record da 100 byte ora, aggiungilo a 150 per un uso futuro.
Aggiungi un numero di versione e forse un checksum in modo da poter sapere quali campi devono essere compilati e avere un controllo di integrità per la validità e sei a posto.

Puoi mescolare XML o altri formati con inserimenti Base64 per alcuni dati specifici e per i campi che hai bisogno di leggibilità puoi usare il solito TESTO