I have a hobby RPG project going called Endtime. My aim is to match the technical, game-play and artistic level of things like Fallout 2, Ultima, etc. Ten year old games. I think that's a feasible ambition for a solitary coder.


However, I won't really get away from a lot of data-shuffling for things like quests and items and such, and I was considering employing a database for easier back-end quest writing and such.

I mean, if I end up having more than 100 quests in my game, it is probably going to be easier to fill out the quest data in a form in a database than it would be to hard-code it in. I could store bulk quest data, dialog trees, the full item list in a database and call those when needed.


So, my question is simply because I am a bit fuzzy about how it would be done, do you use databases in your games and would it be worth trying to think up a bridge? Do you use databases in your games at all? If you do, do you use SQL or non-SQL ones?

Or if not, is it a really bad idea to use databases from an efficiency standpoint? Are they just too slow for things?

i am using mongodb but join not enable and need to learn map-reduce

Databases are not the be-all and end-all of storing information.

I'd suggest looking into building a simple tool set that stores your data in a custom format or leverages an existing tool like XML/JSON/YAML/etc. You can knock together a tool to edit your game content in C# in a few hours; in the same time it'd take to integrate a database, design a schema, and start filling out "forms in a database", you could have some custom solutions that do precisely what you need and can be extended as you see fit whenever you like.

For perspective, most major game engines use custom data storage systems for precisely these reasons.

Unless you are running massive numbers, most database systems are massive overkill for what you need. That said, they do solve a lot of problems that you might encounter ( transactions, concurrent request/race situations ) and theoretically are well optimized. If your data fits nicely to the database format it may certainly be a good way to go.

Consider a lightweight embeddable database like Firebird. It has ADO.net and ODBC connectors, making it fairly easy to access. ApochPiQ is right though, in many cases a database isn't really the best solution. In this case, embedding your data as code is a good fit. The above mentioned JSON, as well as LUA are both quite capable in this regard.

Databases are not the be-all and end-all of storing information.

I'd suggest looking into building a simple tool set that stores your data in a custom format or leverages an existing tool like XML/JSON/YAML/etc. You can knock together a tool to edit your game content in C# in a few hours; in the same time it'd take to integrate a database, design a schema, and start filling out "forms in a database", you could have some custom solutions that do precisely what you need and can be extended as you see fit whenever you like.

For perspective, most major game engines use custom data storage systems for precisely these reasons.

I agree with ApochPiQ. I worked on a game where we used MySQL databases to manage everything -- quests, stats, players, items, etc. If I had to go back and do it again, I would have just wrote a custom storage format. The amount of trouble that those databases caused was unbelievable; especially when you have more than one programmer working on the game.

Thanks guys. I really appreciate your comments. I'll have a look at XML or JSON if I can get that to work with Unity Free, which is my engine of choice.

In my opinion, databases are meant to solve a different problem than what you describe. They are designed for (hundreds) thousands (millions) of users to insert/remove/query the information in them concurrently. Not for a single programmer to store inter-related program data. As others have pointed out, if you use a professional database solution, you will add complexity to your own life with very little return on investment.

In my opinion, databases are meant to solve a different problem than what you describe. They are designed for (hundreds) thousands (millions) of users to insert/remove/query the information in them concurrently. Not for a single programmer to store inter-related program data. As others have pointed out, if you use a professional database solution, you will add complexity to your own life with very little return on investment.

Oh, there is a massive return on investment, especially if you are creating say.... an MMO.

But it all comes down to weighing the upsides vs the downsides, and the reality is, most games dont use a portion of the ability of most databases on the market.

That said, MySQL is a notorious pain in the ass, so that would be a big part of it. There are many databases that were designed specifically to be embedded in an application and they will give a much different experience.

I'm an on- and off player of Eve Online, and my thinking about databases in games started because I know that Eve invests a lot in their database. Of course, Eve is an MMO with hundreds of thousands of players, so there is the question of scale. But it got me started thinking about the utility of databases in games.

Again thanks everyone for your comments. It's most instructive.

Even traditional relational (SQL-oriented) databases are of questionable utility to a modern MMO. Reliable distributed data storage is often more valuable than strict ACID compliance and the other features of relational DBs, at least until you get to the archival/long-term-retention state of affairs.