¿Cuál es un buen formato de archivo para guardar los datos del juego? [cerrado]

Necesito guardar algunos datos personalizados del juego. Mapa, jugador, etc.

Todos ellos tendrán "subobjetos". Por ejemplo, un mapa y un mapa tendrán una "matriz" de mosaicos. es decir, datos jerárquicos. Ojalá nada binario.

¿Cuál sería un buen formato para estos?

Hasta ahora he considerado:

Serailización: esto es RÁPIDO y fácil, pero tiende a romperse cuando cambio las clases subyacentes :(

XML: Realmente odio analizar esto. Mi caso de prueba tenía más de 100 líneas de código y parecía tener toneladas de "trabajo ocupado" incluso para un formato muy simple.

INI: sería realmente torpe para los datos jerárquicos.

Protobuf: nunca lo usó, pero lea que tiene que hacer un montón de trabajo manual y saltos si cambia de clase.

¿Otras opciones? ¡Es por eso que estoy aquí!

Editar: esto es Java por cierto.

Edición 2:

Me decidí por la "serialización binaria controlada" (ver más abajo).

Pros:

• es rápido

• es pequeño (en el disco) y se puede comprimir / descomprimir fácilmente durante la lectura / escritura.

• it's super easy to read/write from game and toolset.

• I can decide what to include/exclude of the object.

• Objects/Data can be nested.

Cons:

• Can't edit it by hand (like XML, YAML, etc)

• Can't easily read/modify it with scripts

• Java Serialization by default is pretty slow/bloated compared to other implentations, but it's stable and works

To display hierachical data, YAML or JSON would be good options. They are far simpler and easier to parse than XML.

Another option would be a "controlled" binary serialization process. Every object writes it's state out in a controlled way, i.e.

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

id Tech 4 (Quake 4 / Doom 3 engine) uses such an approach.

A well made binary format has really got all the advantages, it's fast, reasonably small, and as flexible as you make it.

Making a binary format you are bound by no rules, which is a great advantage, but ironically it's largely what has given binary file structures a bad name. XML, JSON and the like makes a lot of decisions for you, they are far from always optimal, but they are reasonably safe choices that will usually help you steer clear of some otherwise common problems.

Identify these problems, design your format with those in mind, and you can make a great binary format.

If you are not experienced/confident enough to make a binary format and the amount of data is small enough that the speed impact will be negligible, I suggest that you use JSON, it's simple, but does the job.

Your choice of file format is hugely dependent on your current toolset and the game you are intending to make. With that said...

Toolset is one of the most important factors when deciding a game file format. If you make a binary format, you have to always ensure that you have the tools to input your game data. This could be as simple as a hex editor, or as complex as Unreal Editor.

I guess the main advantage of XML, YAML, or any other language files, is that you can edit it easily via a text editor. And using an existing standard, it ensures you can't go wrong. But, this is extremely tedious when you have a thousand files, which brings me to my next point.

Game. What kind of game are you making? Why I say this will affect the file format? Because, if you are making something like 2D bomberman, you could get away with a simple text file like:

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

In other words, always go for the most obvious format for your specific data. RPGs are the most complex game genre to make. They require lots of data. But doesn't mean you have to stick a specific format, be it binary or text-based for all data in the game.

• Maps, particles, and other graphical stuff tend to use a custom binary format. Because it's the simplest way to implement it. It's not humanly-sane to describe maps textually. Usually edited via map/level/particle editors.
• Players, items, enemies, skills and quests are statistics that affect game balance. They usually require lots and lots of input and tweaking. I like to do this by putting it in an XML file for ease of implementation, but yet having an object editor for the designers to play with. Best of both worlds.

Generally, you want to describe text with a text format, and graphics with a binary format. The following should give you an example:

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

To sum it up, it is to my fullest recommendation that if possible, you don't script your data, unless absolutely necessary. The end-user doesn't care about how awesome the format is, as long as the game is playable, that's all that matters.

Cheers, roy =)

BSON is pretty nice. http://bsonspec.org/. It is easier to parse then JSON and better at containing binary data, but still has a nice structure. It's somewhat similar to protocol buffers. The downside is that there dosent seem to be a lot of tool support for it outside of mongodb.

EDIT: MsgPack ( http://msgpack.org/ ) is also similar to BSON and seem to be gaining more traction.

What's happened to your custom binary data format? If you are afraid of raw serialisation, write your own system that writes fields as needed, and reads them back. No need for xml, which is indeed overly bulky and complex for situations where you don't need the transparency the format provides. Just define a well-specified file format and stick to it, leaving maybe some room for expansion of your data set in each record by padding them with null values (say you have a 100 byte record now, pad that to 150 for future use.
Add a version number and maybe a checksum so you can know what fields should be filled and have a sanity check for validity, and you're good to go.

You can mix XML or some other format with Base64 insertions for some specific data, and for fields you need readability you can use usual TEXT