Games and Databases

That depends on the type of game and how you're using SQL. For my server, I find a database useful for a variety of reasons.

* Common interface for other applications, such as editing and reporting tools.
* Fast access to specific data, which is useful for features like lazy and/or dynamic loading.
* Features that assist in maintaing data integrity.
* Lots of existing tools that simplify maintenance, backups, and other necessities.

you defenitly wouldnt want to be running sql mid game though you could use it to save and load data,
the only practical example i can think of would be a online game since
1 you could store large ammounts of data in a flexible way
2 it could be connected and syncronized with multiple servers
3 the game could be unifyed with a php based system for a message board

You could use SQLite for offline databases that store information about your objects. I watched an interview with an employee at EA a few years ago, and that person talked about how they use MS Access for storing the stats on the players in their hockey games. Morrowind also used an offline database to store the vast amount of information on the objects it has.

Using a database would make it quite easy to extend the variety of objects in your game. Of course, you would really only need to use a database if your game had a massive number of objects to look after. You could also store static dialog in the database, if you felt so inclined. The possibilities are endless.

Databases also provide a means to store data in a manner that is more robust. In the case of an online game, say an MMO, new kinds of data can be added into the record without breaking compatibility with previous client binaries. Using separate lists would allow this I suppose, but you're still seeking through the files/data, which will be by far the costliest operation. Ideally you want to seek only once and have access to all the information. Databases address both of these issues, maintainability & data locality, in addition to the excelent points brought up above.

I think you're right in the first instance. A relational database isn't what you should be using for this kind of thing.

In terms of archives/saves or even mass data storage you might want to look at Object databases which store objects rather than records as such.

I guess I wansn't exactly specific on what type of game I was referring to. I was referring to online games with many players such as FPSs and MMOs.

Personally, you have it backwards. You don't need a reason to use a database, but rather you need a reason to not use a database. At least as long as you are talking large-scale online games with large numbers of concurrent users. To use SQL or not use SQL is the least important issue. That large number of concurrent users is a much bigger issue. That's what is going to suck up your time if you try the do it yourself approach.

I agree that it is good to use for saving data and archiving, but large amounts of users doesn't require SQL, all you are doing is forwarding dynamic data, the contents of which is not complex. Other than retrieving info for authentication I don't see a use for it in online gaming servers.

You need to look at it from a systems perspective rather than an application perspective. Looking at it simply from an application perspective you just inserted a row into a table. You started a transaction at some point and until you commit the changes that transaction made you can cancel the transaction and back out all it's changes. Fairly simple from an application perspective. It isn't quite as simple when you have 10k other users out there doing the same thing. Without a DBMS you can't just deal with your one little user doing their one little thing as though the rest of the world doesn't exist. You instead have to deal with what the entire system is doing at that instant.

With an online game you're talking a transaction processing system. Yes, certainly, your data access is rather simplistic because that is the nature of tranaction processing systems. It is something you strive for. If your data access gets too complex you lock up the entire system and no one can use it for anything. In and out as fast as you can with a transaction living the shortest possible duration to insure the integrity of your data. It has nothing to do with being a game. Wal-mart ringing up a sale processes data in just as simplistic a manner. Um, UPC code, go get the price and description, add it to the list of items and update the total. Not exactly complex data access. The issue is the concurrency. Particularly when they fire that puppy off to Visa along with every other store in the nation the day before Christmas.

You need to get past this idea that you only need a DBMS for decision support systems and the only reason you need it there is that you are processing such complex queries. Realistically the complexity of the statement has little to nothing to do with the complexity of actually executing the statement. That correlation really only exists in systems with only one or a few users. Depending on exactly what those few users are doing it may not even exist with a few users.