I'm working on a game which could potentially generate rather large save files, and so I'd like to find the smallest (most efficient, if you will) method of saving the game's data. I would need to save block types along with entity positions. Would a binary approach generate a smaller file than a text-based one? If so, how do I store the binary data?

  • 2
    \$\begingroup\$ It seems to me like you are overanalyzing this. Does it work for you? When yes, why change it? When no, what drawbacks did you notice? \$\endgroup\$
    – Philipp
    Commented Sep 13, 2013 at 21:33
  • \$\begingroup\$ @Philipp It works absolutely fine, but I've never really seen this tactic implemented in a game, which leads me to believe that I should be doing something else. Additionally, I'm going to eventually need to implement a level saving system in another game which could potentially create quite large save files, and so I believe that storing information in plain text could perhaps be inefficient on such a large scale. \$\endgroup\$
    – caseif
    Commented Sep 13, 2013 at 21:36
  • 1
    \$\begingroup\$ Whatever you program, there is never the right way to solve a common problem. Only the way which works best for a specific project. \$\endgroup\$
    – Philipp
    Commented Sep 13, 2013 at 21:38
  • \$\begingroup\$ @Philipp Perhaps this specific project would be best with plain-text saves, but I believe I'll need to find another way of saving the data for a separate project. \$\endgroup\$
    – caseif
    Commented Sep 13, 2013 at 21:41
  • 1
    \$\begingroup\$ Please note that "text" is "binary," it just has a human friendly editor called Notepad.exe. The choice is all about perspective and what you need it for =) \$\endgroup\$ Commented Sep 14, 2013 at 19:39

1 Answer 1


It's not just about storage efficiency (and with today's disk sizes it could be argued that storage efficiency is among the least of your concerns), it's also about how fast it is to load data and how easy it is to translate your loaded data into something you can use.

For speed of loading, binary wins hands-down. It can be just as simple as a single fread into a previously allocated pointer, then your data is loaded and you're ready to go.

For translating that into something you can actually use, I'd argue that's more of a design issue than a format issue. If you build a design that requires complex and involved serialization, then it's going to require complex and involved serialization, irrespective of whether you use text or binary. On the other hand if you design simpler, then binary can win again - that single fread can result in everything you need loaded and correctly in-place, compared to having to write and debug a text-parser.

If despite this you still opt for text, then I'd advise that you at least design a single common format that you can run through a single common parser, otherwise you'll end up with multiple different, specialized, and useless-for-anything-else text-parsers in your code. Which is OK if you like writing text-parsers but not OK otherwise.

Ultimately it's up to you. Text does have the oft-cited advantage of being human-readable, but is that important for what you want to achieve? Are you designing a format to be read by humans or read by a machine? If you want human-readability then text is the way to go, if you don't need it then you should seriously consider binary.

  • \$\begingroup\$ Yeah, I think binary sounds like the best choice for this scenario. There doesn't seem to be a downside, especially considering the fact that the files won't ever be read by humans anyway. \$\endgroup\$
    – caseif
    Commented Sep 14, 2013 at 2:46
  • \$\begingroup\$ The downside to binary systems is that they aren't very extensible. Proprietary formats require manual modification of code if you want to make most changes to the file format. This can be a problem for content pipelines that have multiple tool sets leveraging the same format. Human readable formats such as XML or JSON or whatever make iteration quicker at times, because the files can me hand modified, and you don't need engineers to work with simple iteration. Its not uncommon for tagged parsing to be used in dev, and binary load-and-go for release. \$\endgroup\$
    – Evan
    Commented Sep 14, 2013 at 14:29
  • \$\begingroup\$ @Evan you can make binary extensible and you can make text non-extensible \$\endgroup\$ Commented Sep 14, 2013 at 16:29
  • \$\begingroup\$ @ratchetfreak How exactly would that work? \$\endgroup\$
    – caseif
    Commented Sep 14, 2013 at 16:45
  • \$\begingroup\$ minecraft's NBT format is very extensible, and I have seen (and admittedly created) a non-extensible text based format \$\endgroup\$ Commented Sep 14, 2013 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .