Programming experiences

[debo]

Originally Posted by Derakon

Realistically these days there's only two reasons to use custom binary file formats:

1) You want it to take an extra two hours for the hackers to figure out how to modify your savefiles / the idea of people being able to easily modify your game fills you with shame and horror.
2) You're writing a program for older mobile devices that don't have the storage/processing power to effectively make use of text formats.

3) U r L337

[Gorbad]

Originally Posted by Derakon

Realistically these days there's only two reasons to use custom binary file formats:

1) You want it to take an extra two hours for the hackers to figure out how to modify your savefiles / the idea of people being able to easily modify your game fills you with shame and horror.
2) You're writing a program for older mobile devices that don't have the storage/processing power to effectively make use of text formats.

4. You plan to store tens of millions of save/data files (Massively successful multiplayer games)

But anyway, yes agree to generally use a txt/xml/yaml/json format, and I'd even go so far as to say that if you have speed enough, don't use C or the like, but an interpreted language (Python/Perl/choose your preferred poison).

[Derakon]

Originally Posted by Gorbad

4. You plan to store tens of millions of save/data files (Massively successful multiplayer games)

Then you use compressed text. zlib is not hard to work with and will get you similar space savings as a custom binary format would. Heck, we have a custom binary format at work (I didn't choose to use it!) and compressing it gets us a 50% reduction in file size simply because it's not well-designed for space saving (it contains a lot of raw image data).

However, I suspect that MMO saves are stored in databases instead of flat files, since there must be all sorts of juicy analytics that the game developers will want to be able to run.

[Gorbad]

We store many items (non game related) in, for example ASN.1 formats, which tends to be highly efficient (and easily readable again if needed).

The smaller items/larger numbers stuff indeed goes into clustered databases, but keep in mind that for companies wanting to keep data for longer periods, even one byte saved means massive savings (not only storage, but also transport).

[fph]

Originally Posted by Derakon

Then you use compressed text. zlib is not hard to work with and will get you similar space savings as a custom binary format would. Heck, we have a custom binary format at work (I didn't choose to use it!) and compressing it gets us a 50% reduction in file size simply because it's not well-designed for space saving (it contains a lot of raw image data).

Does this mean Angband savefiles are scheduled to become compressed xml soon?

<item><name>The Phial of Galadriel</name><bonus type="searching">+1</bonus><bonus type="light radius">3</bonus></item>

[Derakon]

Originally Posted by fph

Does this mean Angband savefiles are scheduled to become compressed xml soon?

I dunno about Angband, but Pyrel will most likely be using plaintext JSON for savefiles. I'd guess (completely blind) they'll probably end up in the 50kB range, which is not exactly going to break anyone's hard drive.