   XML or database for storing game data?
  Here is my question: when should you use XML to store game data and when to use database? I am guessing with static data that never changes such as monster stats (for example monster name, level, attack points, defense points) XML would be a good candidate. But if the data changes often (or in other words data that requires a lot of read/write operations) an actual database might be a good choice.So anyway, what does everybody think on the issue?   
  It depends.XML is fine for small, simple stuff -- but it's verbose and slow to parse. For larger content volumes where load time can start to be an issue, I'd use a binary format, preferring XML for intermediate data and iteration (e.g., debug build) storage. Most games don't need a database implementation to store their data. Flat files are perfectly viable for load-time data, and the data that is heavily modified at runtime doesn't need to be written to disk all the time; just keep it in memory and modify it there. This is especially true of single player games. Persistent multiplayer games usually have some kind of database-backed storage for all kinds of persistent data on the server end.   ;  XML is good for on-disk storage, when you need to access your file with many distinct programs (including text editors to manipulate the contents by hand), or if you have structured data and don't want to write your own structured data serialization methods. It can be safely used both for read-only configuration data, and for read-write saved data or options. Databases, on the other hand, serve to provide additional benefits. They provide improved data access though an expressive query language, transactional behavior (where a crash in the middle of the game leaves the data in a valid state) and good in-place manipulation performance. This makes databases a good choice for persistent game data (such as an MMO server) but not a good one for saving and loading games. Last but not least, using an in-memory representation (without the associated storage) is by far the fastest if you need repeated and frequent access. Of course, this representation disappears when the game application stops, so you have to convert it to one of the other representations (or perhaps a binary file format of your own) when this happens.   ;  Both? http://en.wikipedia.org/wiki/XML_database;  Often data basses are real over-kill for most single player games. I recommend using XML and creating you own editor that saves to both XML and binary format. While working on the game work with the XML, as it is easy to change your classes and still use your same XML files (for example if you add some variable to a weapon class, but your saved XML doesn't have it: when you load a weapon that variable will just be the default value), while adding and changing variables working with binary files is slightly more tedious.Then once you want  think  your done you change your game loader to load the binary versions and ship with those files rather then the XML so your players can't just open them up and change all the stats.I originally was looking at SQLite for my project, but I realized that it was WAY more then I needed and not as easy to use as tinyXML.just my 2 cents.-vs   ;  One solution I've seen in a couple of places was to create an automatic serializer based on a known structure definition:typedef struct quux{    char *foo;    int bar;    float baz;    struct quux *next;} quux_t;structDef_t quuxStruct ={    { "foo", offsetof(quux_t, foo), FIELD_STRING },    { "bar", offsetof(quux_t, bar), FIELD_INT },    { "baz", offsetof(quux_t, baz), FIELD_FLOAT },    { "next", offsetof(quux_t, next), FIELD_STRUCT }}So you have a single call that reads that info and uses it to manipulate the struct accordingly, by knowing the offset of the field and its type, you can play with memory to read and write data.It would be a total bitch to implement for C++ though, which is why we have other libraries like s11n and boost_serialization [wink].   ;Quote:Original post by vs322Often data basses are real over-kill for most single player games.[...]I originally was looking at SQLite for my project, but I realized that it was WAY more then I needed and not as easy to use as tinyXML.Hmm, I can't say I'd agree. Once you write a small number of wrapper functions (eg. about 100 lines) to handle reading and writing your structures from the database, you find using SQLite no more verbose than TinyXML, but with far more power over the data you can query. For simple serialisation, both approaches work out roughly the same, but hard data querying and manipulation is so much better with a relational database once you have a grasp of SQL.True XML gurus might be able to match that expressiveness with cunning use of something like TinyXPath, but I'd expect that SQLite would win on performance.;Quote:Original post by KylotanQuote:Original post by vs322Often data basses are real over-kill for most single player games.[...]I originally was looking at SQLite for my project, but I realized that it was WAY more then I needed and not as easy to use as tinyXML.Hmm, I can't say I'd agree. Once you write a small number of wrapper functions (eg. about 100 lines) to handle reading and writing your structures from the database, you find using SQLite no more verbose than TinyXML, but with far more power over the data you can query. For simple serialisation, both approaches work out roughly the same, but hard data querying and manipulation is so much better with a relational database once you have a grasp of SQL.True XML gurus might be able to match that expressiveness with cunning use of something like TinyXPath, but I'd expect that SQLite would win on performance.Perhaps your right, but with the data being user readable / editable before I had my other systems setup made it vary easy to hit the ground running. On the performance side of things I am sure you are right- thankfully I am not doing any XML parsing at runtime- only doing it at load time, and it is defiantly slower than a binary and I image slower then SQLite.Perhaps I will re-do my system when I get back to making weapons / items / monsters etc, and switch to a database. I really liked the idea of it before I got my current system up and running, being able to do mass changes seems like a big advantage of a data base. There seem to be other advantages too, I was just a little confused as where to start with SQLite.BUT I still believe that for building, or hacking a system together that you're not 100% sure of the design, is very easy to do with XML.   