Database as game data repository?

Question

Hi,

Has anyone had experience writing a game engine or demo engine using something like a SQL database to store game assets? Does it make sense to use in that context? What would be the advantages and disadvantages?

Thanks!

Answer 1

This is just a personal opinion (no hard data to back this up) but I would say it really depends on the nature of the game and what kind of assets you would be storing. If it's a slow game (think puzzle or something) it could work. If it's a fast one or one that constantly loaded textures or something you would probably run into performance issues with the queries.

You could use System.Data.SQLite for a state store (it's lightweight and hosted in process). But again, most games I have seen do a direct data dump of their state when saving.

So really, I would probably recommend against using a SQL engine for storing game assets.

Answer 2

Game assets tend to be fairly static - once you've designed and shipped the game, you tend to know both a) exactly what data you're working with, and b) exactly how you want to access said data. Since your data is fixed, and you're not wanting to run dynamic queries or get dynamic results, chances are a relational database isn't the best solution.

Answer 3

To reiterate what Joshua said, most of the games use an on-disk database. Lets use Quake as an example (as you can get the source code). They store all the assets inside a .pak file (which is really a zip file).

An engine was created to easily extract out of the file the asset required to be loaded. This meant a little overhead on the seek and decompression but all the main assets (textures/skins/sounds) were loaded during the creation of the "room" in which game play took place.

It does depend on the nature of your game but I think most commercial release titles use something similar to this to hold the required assets.

Checkout IO Quake or Nexuiz or Tremulous. Sorry if I repeat some knowledge that you already know.

Now you could use a database to store scoring, game progress and other such meta data, but I too would advise not storing these large binary blobs inside a database (again, it depends on your game)

Answer 4

I don't see how it matters at all what medium your game assets are stored in as long as loading and periodic saves take place fast enough. I would assume that the SQL database would be something like SQL Server Compact Edition, SQLite, VistaDB or some other client-side database. Perhaps even something like DB40 that is object-relational instead of SQL-based. Of course, the assets would be cached to memory for in-play usage and then persisted back to the database at save-game intervals.