Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for library/technique for storing my game resources - levels, object (effects,world info), items(price,effects,...), NPC(visual info, behavior), everything except graphics/audio stuff. I've seen lua used for Awesome WM configuration. protobuf looks good, but it seems to be designed for network communication. I've tried to write my own parser, but as the project grows it's more and more harder to manage it and catch all the bugs.

My requiremets:

  • stability
  • easy extension of data without need to convert older versions to newer
  • good(don't have to be the best) performance of loading
  • not much coding
  • not XML!
share|improve this question
What do you mean by game resources? – Kylotan Nov 25 '12 at 13:45
@Kylotan I've put it into question :) – kravemir Nov 25 '12 at 13:50

Note that "what technology to use" questions are considered non-constructive on this website, but I will still try to help you.

A less over-engineered alternative to XML is JSON (Javascript Object Notations). Parser and serializer libraries are available for most common programming languages.

When you have a lot of assets and you plan to manage them primarily with selfmade tools, then using an SQL database would be a good idea. SQLite would be good for this use-case, because it can be integrated in an application as a library and doesn't need a server. But unfortunately it's hard to come up with a database schema which is upward-compatible.

share|improve this answer
found – kravemir Nov 25 '12 at 14:21

I'd recommend either string maps or basic serialization.

  • string maps - all data is converted to strings and stored into dictionaries. Pros: changes won't necessarily break old save files, can inspect with a text editor, can use JSON and similar formats to store the data. Cons: might be a bit slower with huge data sets.

  • basic serialization - byte buffer, read/write functions for elements of each type ([unsigned|signed] int[8|16|32|64], float[32|64], byte buffers). Pros: lightning-fast. Cons: changes will most likely break old save files, not even a hex editor would help much here.

Both methods will require writing manual load/save functions for each serialized object. All the usual rules of inheritance and composition apply here (can reuse functions to serialize included objects) so it won't seem that hard in the end.

To me, it would most certainly beat writing obscure wrappers and configuration files for a complex system. But I suppose you've got to try both things to see what you like more.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.