Is a SQLite Database Suitable to Store the Building Blocks for Dynamic Content?

Question

I am trying to make my own game for fun, it is basically a 2d side scrolling shooter, with dynamically generated enemies, levels, loot, and some other things. Currently I have dozens of XML files that define pretty much everything when it comes to the content, along with some constraints to keep things sane. Often times certain things like Weapons or Monsters are composed of several randomized sub components, that get picked out of a pool, according to factors such as rarity, the player level, and the game level.

Currently the way I have it setup, is where during initialization the game creates several factory classes (stuff like WeaponFactory and EnemyFactory), these parse the XML and store the XML's data in a more manageable format. Creation is simply done by invoking a create method, and passing the required parameters (i.e. player level, monster level, etc), these parameters are taken into consideration for what should be generated.

Anyways I was wondering if it would be a better idea to use a SQLite database to store all this information? I have looked around, and it seems to be a mixed response. Does anyone have any sort of insight into this? I am using C++ and OpenGL currently.

EDIT

I probably should have been more clear, I was more or less asking is it actually a usable way of doing this kind of stuff. My main concerns lie in the fact of choking the Database with requests. Reality is this game will never see the light, and has technically been done as of a few weeks ago, however I decided to go back retool the engine to use Box2D Physics. This is more a learning process, than anything.

Answer 1

Here's what should weigh in on your decision:

XML:

• (+) You already have the system implemented - no additional work required
• (+) Easy to mod the game for people with minimal technical skills
• (–) Wasteful with space

SQLite:

• (+) Faster (although it may not matter)
• (+) Uses less space (may not matter)
• You could write a modding UI, or even make it part of the game
  • (+) If you do, would be a great feature but (–) It would require considerable work
  • (–) If you don't you make modding inaccessible to almost everyone
• (–) You have to actually write it and make it work, and comb through it for bugs (although in my experience with SQLite it's not a big pain, and as with everything, if you've worked with it before you'll anticipate the bugs you've made before).

Final thought: In my experience with data SQLite makes devs happy and users slightly defeated if they are curious enough to actually wonder (where is the data stored) think it's inaccessible to them (stored in the cloud, in an encrypted file, etc etc) and go, "meh, whetever". When all is said and done, I've been much happier with SQLite and other DBs for data, and if your data was in some kind of ugly CSV file or something, I would advise you to go to SQLite, not XML. The main dilemma for you, is that with XML you're done with that part of the game. With SQLite, you need to put in work. I'd say leave it until everything else is at least working, so you have a full prototype. Then you can try to sell/spread your game and roll SQLite in a patch.

Answer 2

Do you actually have a problem with your existing system? Or are you just asking, "would it be better if..."?

If you have no problem with the current system, keep it. Don't change technologies during a project unless you need to. Given the simple use case you describe, I can't see any reason why an SQL database would work better than your XML.

Note that SQL is optimised for random access to large amounts of data that are left on disk, whereas XML is optimised for being read in to memory and queried in memory. XML is also much easier for you to edit by hand. Given these factors using a relational database is rarely that beneficial for small games that don't store much data, and is better for games that generate a lot of data as they go along.

Answer 3

Unless for some reason the possible content changes at Runtime, choose whatever format you want for content creation (And since you already have XML up and running, stick with that.) then as part of the game build step pack it down to a binary format that your game can understand. This reduces the time and memory footprint needed to handle text processing, while you can still keep the content mergable in your source code control provider. And of course share the code between the tool writing the binary format and the game reading the binary content if at all possible!