Eric Heimburg makes a case for using a database to avoid extra work on the indie scale; for his purpose, yeah, Smart Fox may work out well. I would want to talk to someone who has had problems with their database layer and find out how bad it was. I hate reference customers who have nothing but good things to say — tell me about how tough it is to fix problems.

The downside is that saves are written out to a file, and there was a long save cycle in the game when that happens. That could probably be avoided by duplicating the memory and having a separate thread write out the data. The other big problem is that a crash meant that the game state has to be rolled back to the last save file. But, as you point out, this isn’t exactly unique to M59.

Especially if you are talking about the indie scale of things, a database can cause a lot of headaches. DBA isn’t something most people pick up as a hobby.

Would it make sense for an asynchronous MMO-style game (like a browser game) to rely on something other than a relational database? Regardless of its purpose, I suppose that a browser game would be more like a website than an MMO in terms of database structure, but that might depend on the way the game works.

Memcached is a good idea. I should have thought of that. It’s a cheap effective way to get the in-memory data store you want. I know of one MMO which stored everything including world data in SQL, if I’m remembering correctly, specifically for ease of updates. I was always a bit leery of the idea because of the speed issues and such. Memcached would work really well there, unless of course you wanted a user-modifiable world.

There’s a lot more R/W information then character data – basically anything that moves or can be interacted with. To follow your example, monster info isn’t static – the monster moves, it’s condition (HP, etc) changes, and its behavior changes based on that condition.

Very interesting topic. I never bothered to think about the data model.

If I were at an MMO startup, I’d probably want a relational database for some things. Account info, for one, and payment information. This is what they’re for.

And I’d probably want some technology to dump from the custom hot-running dbs periodically to a reporting relational database. This is what could power web-based data. And also what you could run ad-hoc data mining queries on for R&D purposes.

For rapid read-only data, like monster info – really, I’d be tempted to just run it all through memcached or something, flush the cash on server patches. And at that point, eh, you can store it in whatever makes it easier for your tools, since it’s getting served from the cache in active use and that’s _fast_.

And then that just leaves character data, including inventory, as the lightning fast heavy read write element. And that you optimize like hell. Yeah, wouldn’t use a heavy relational database. I _would_ like to be able to dump it to one, and restore from it, because losing this stuff loses customers.

Hmm, I’ve never worked on an MMO, but it’s fun to think about the challenge! Actually, this is a good interview question, how would you set up the database architecture for an MMO – candidates already know the space, and you can see how they think, which is what I want to know in an interview.