Well, I''ve done a search and this doesn''t seem to have been discussed too much. In the past I''ve written my own data format and used that in a game. I never finished the game, but that''s beside the point. Now, when looking at Subversion (a cvs-like system) I noticed that they use BerkeleyDB for storage, and I started looking around on the net for similar systems. Basically, what I was looking for was embeddable databases as I wanted to see if they could be used in games. I am trying to use as much existing code as possible as I am working alone and if I did everything by myself, I''d never get anything done, I''m afraid. Something like MySQL wouldn''t come in handy, obviously, as it wouldn''t exactly be a cool thing to install it on the machine of the user. However, when using an embedded database, the user wouldn''t even have to see you are using a database at all. And it''s a bit faster as it doesn''t have the overhead of going through TCP/IP and stuff. There are several solutions out there that are pretty simple and don''t use too many resources, so far I''ve mainly taken a look at Berkeley DB and Metakit. Now, what reasons are there not to use these? Sure, they might reduce speed a bit, as they do have more features than I would have implemented in a resource file system. However, on the other hand, data can be stored a lot more flexible. I can put strings in there, scripts, binary data, everything, and access it all in a similar manner. Obviously, the answer to this question will very much depend on the type of system used. Anything you could recommend? This really is a new area for me as well, and I''d like to hear your opinions on whether this is a feasible approach or not.

i think that you''ve already accepted the obvious: database usage largely depends upon the target system and game type.

i think there are many advantages to using a sql compliant database. the time saved in designing and coding your own data formats is perhaps one of the best reasons to use an existing database. in addition, if you can find an open source database, you can modify the code to better suit your needs. for my java projects, i''m working with a stripped-down, self-modified version of the hsql database, which includes field-level encryption and some extensions to the sql language.

i think that if you decide your game would work best with a database ensure that you consider the following things:

1) the memory footprint of the database itself
2) remember that most databases are designed to support transactions and typically are not designed for the speed of pure read operations.
3) the difference between a really fast and a really slow read operation is usually found in the database design. if you''ve never designed a relational database before, do some reading. In general, however, a flat table hierarchy and appropriate use of indexes should provide decent results. do not over-use indexing...it will generally produce the opposite result from what you would expect.

hope this helps...

So you would use it to hold the actual game data? Maybe I understood you wrong though, but it sounds like a weird system to me if you are using it to keep track of bullets and whatever. Might be hard to do with an existing db anyway. Interesting idea though.

I was more or less just taking it as a replacement for loading resource files.. Just seemed like a good idea as the db would take quite some load off you.

Hm, don''t think there is a database geared at games programming.. I''ve only taken a look at those two that I named so I really don''t know a killer app.

my bet is that one might find less than adequate results from using a database to track game data that has a short life span, such as a bullet. numerous inserts, updates and deletes will overly burden any application.

i would consider using a database when time and processing isn''t a prevailing factor, such as in a turn-based game where the ai is expected to take a couple of seconds to make a decision and a few dozen queries (if necessary) won''t produce a heavy strain on performance or expected game play.

storing strings or scripts or some other sort of similar resource might also be a good use for a database. as it has been mentioned before, it depends on the application. however, i would certainly recommend building some sort of caching mechanism between the database and your calling application. the cache will dramatically increase performance in scenarios where the same resource is required over and over again.

i was considering taking some time to write an article for gamedev on the subject of database design and the implications it has for game development. is anyone interested in seeing something like that?

i''ve never seen the guts of a mmorpg so i couldn''t say with any certainty what kind of data is maintained in a database. however, it would seem to me that data persistence and state management play a key role in the success of such a game and a database could alleviate much of the headache involved in maintaining a data layer.

as for an article, i think my focus would be on design and performance issues that apply to databases in general and then the application of those generic issues to game design. i wouldn''t want to be too specific yet, as i haven''t fully completed a production quality game using a database as my data layer and would not want to publish any findings that have not gone all the way to production. however, there are certain rules about databases that apply regardless of their application. i think those general rules might be of benefit to the community.