I'm not sure, but even a big mmo like Aion is using xml to save data- can't be that wrong

Having seen SQLite used for game development in the past, I'm actually more against using that than using more traditional DB systems. It claims to be ACID compliant but it's easy to break that aspect if you implement it wrong, and treating it like a genuine database is begging for weird bugs.

I stand by my original statement: by the time you integrate even something like SQLite, get up to speed on the tools, etc. you can hammer out a fully custom solution that beats the pants off a generic database system. Existing libraries for storage formats are so prevalent that there's no call for rolling your own storage solution. You can save all the effort of integration and convert it into effort making your ecosystem better, and that pays off a lot more over time in my experience.

MaxieQ,

Game development office database and online game server database are things to research and eventually launch. As your organization grows, the need for these two databases will surely increase.


Game source code modulization might be better served by avoiding a database integration in the game source code. It is quite easy for data in a database to get lost or detached from the game source code. If changes in game code will require a change of database structure, then you just doubled your work and multiplied your risk of a broken game.

On the other hand, maintaining a database can make changes to data itself quick and easy if the coding is safe and reliable. Tree and kinds of data hierarchy would be a must for complex games in general if you are going to use a database.

I am sure that fans of game databases will tell you that they are glad they learned and integrated them. On the other hand, with games slowly getting more complex by the day, the need for dynamic writing with modulization seems to me to work against a database.


Clinton

I personally cant imagine an MMO-scale project not using a traditional database... But then again im a profesional plsql developer who spends his work day writing tedious finance and stock related batch jobs or designing and implementing new bussiness applications starting wit the database and ending with the actual application so I might be biased... In my personal project http://www.gamedev.net/blog/blog-807/cat-252-strife I use an oracle database and for me it fits in perfectly. Although. I dont store any quests or items in the database, I have a custom format for that since it makes more sense to me. The database is instead is used to store things like accounts, characters and links from a character to all its items and quests. Meaning it only stores id's for quests and items in the database but the actual items and quests are stored elsewhere since It doesn't seem benificial to store static data in the database (items and quest doesnt change while the server is running).

EDIT: Another reason why you dont want to store static quest and item information on your server side database is that the client also needs access to it... If a player wants to read a quest the server doesnt (or at elast shouldnt) send over the complete quest dialogue and everything else about about the quest. Instead it should only send over a quest id and then the client should look it up from its own data)

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.

Having played around with NoSQL databases recently ( CouchDB ), I can't imagine they are the answer! Maybe my brain is too wired to think in terms of tables, but my god the experience sucked beyond simple document storage. If you are storing your data as a blob ( say a chunk of JSON ) that you grab, update then push back to the database, it works smashingly, but updating a single value within that document causes an entire new revision to be created. Now, storing files in a NoSQL database is an order of magnitude easier then a relational database, but actual data, not so much.

[quote name='Serapth' timestamp='1354027879' post='5004528']
Having played around with NoSQL databases recently ( CouchDB ), I can't imagine they are the answer! Maybe my brain is too wired to think in terms of tables, but my god the experience sucked beyond simple document storage. If you are storing your data as a blob ( say a chunk of JSON ) that you grab, update then push back to the database, it works smashingly, but updating a single value within that document causes an entire new revision to be created. Now, storing files in a NoSQL database is an order of magnitude easier then a relational database, but actual data, not so much.

Well.. that's one example of a NoSQL database. Compare that to Redis (http://www.redis.io) which is used by Blizzard Entertainment, Stackoverflow, Github, Flickr, Craigslist.. we use Redis for custom news views on the frontpage as well as for real-time access to member data in the Top Members section (http://www.gamedev.net/sm/)

Blizzard uses an 8 node redis cluster for serving avatars in World of Warcraft. Redis is an in-memory data structure server with persistence capabilities.

Also with your situation games not necessarily save in realtime to disk.. with most it's sufficient to do periodic checkpoint saves.
[/quote]

I actually wanted to use Redis, it seemed like the much more sane option than CouchDB. There is a gigantic problem I ran into here.

Redis isn't on Windows yet, at least not in any official capacity. It has been in a "coming soon" state for far too long. What I heard about stability of the Windows port was... not good.