c6burns wrote:I've had this discussion many times (sql vs nosql, relational vs heirarchical data model, etc). I've been outright told that SQL solutions aren't powerful enough for the type of real-time distributed app that an MMO game is, but I just don't see it that way. The type of data you are storing falls neatly into relationships, and you can even scale by frontending your SQL solution with a NoSQL solution. For example, memcached (simple key->value nosql solution) in front of a mysql or postgres cluster is very scaleable and you get to retain your easy relationship management.
Yeah, the main problem in these kind of discussions is that most people used to work with dbs are used to do online services, which have to be efficient at the cost of users not always having the same data; while for a MMO, there have to be a unique "reality" state of the world which keeps everything in sync so that representations are equivalent for all users.
This is important (both for fairness and being able to have coherent interactions between game objects) but also unique compared to most online services.
I have discussed with a NoSQL specialist about how to use something like MongoDB for a game state, he first thought I was wanting to make a game website service. Once he realized it had to be the full state of a game, shared among users, he stopped and said, just use MySQL/MariaDB. The advantage of most NoSQL db is in their easy node disptach.
However, it's still interesting to use some of these dbs for their high speed of access (depending on the kind of games) or for being able to change the model easily (in document dbs for example).
I've made several "small mmo" games in Flash on the client side and java on the server side that used memcached so I see what you mean. The only important thing to understand in the case of mmo is that there have to be a unique truth of the state of the world, there is no way you can duplicate it without killing performance. However, you can split that world into several databases, which works well until there is a place that everybody wants to go to.
c6burns wrote:
I was surprised to see MSSQL as the choice, but one thing I often recommend is to go with what you know, as (in my opinion) it is better to become a victim of your own success than to not get your project off the ground. Especially in a team of two ... if things get off the ground more will join the team and some brave soul can take over the data situation. Switching away from MSSQL would not be a difficult task down the road, as long as you don't use anything specific to TSQL or whatever their implementation is.
I agree. Using a SQL database have at least the advantage that if you don't use it in a too db-engine-specific way you can migrate to something else without much trouble.
Anyway, well done guys! (forgot to say that)
