I'm working on a realtime multiplayer game that will require a database (for features such as player profiles, friends, unlocks, news, etc.) This is a standard PC game (not browser-based) and will use a client-server architecture. I am new to using databases, and have done some research over the past few days when I stumbled upon the heated debate: RDBMS vs NoSQL. Currently I am leaning towards NoSQL but after reading about the uses for each (RDBMS and NoSQL), I'm tempted to use both. I know that may seem strange, but let me explain my situation:
My team has a shared webhosting package that offers unlimited mySQL storage and bandwidth, the only caveat being that we can only have 25 connections open at one time (shared hosting rule). I am intending on using this for my website (a typical usage no doubt) in order to post news updates, support community features (like comments, uploading fan art, etc.) and the like. That's all fine and good - but! this is where things get interesting... I want to display this same information that is posted on my website, in-game. This means using mySQL for both my website and my game. In addition to news posts and the like, I plan on using it in-game for things like chat and a server list. I am concerned about that 25-connection-rule mostly.
Which leads me to ask Question #1: Will this work and is there a better alternative?
Now besides this, I have read about how well NoSQL performs and is suited for realtime games (I could be wrong, I've walked through a huge RDBMS vs NoSQL flame war to get here and probably am burned). Basically, I would like to use MongoDB for all of my game object data.
And again, it will be helpful if I provide some context: I have found a host (MongoLab) which offers a 240MB MongoDB package for free, which I intend on using until it's necessary to upgrade. Given 240MB, I've calculated that I will be able to store roughly 60,000 players (if each player is roughly 4KB and we ignore other things that might be stored). The storage space, and having to pay for more in the future (should our game be successful) is not a problem. The only reason I currently intend on using MongoDB for all of my game object data is because of how often this game object data will be accessed (such as whenever a player is killed, picks up an item, fires a gun, etc.) I also like the straight forward schema-free documents (which make it easier to map game object data). I should note that, at one time, there will only ever be one server writing to a player's profile in the database (the server the player is in).
I intend on using the same MongoDB in my website, to display player profile information (I'm not concerned with complete consistency, some delay from in-game updates is fine). Which leads me to my second question, Question #2: Is this a good idea or is there something better I should do?
The game will have a start up experience similar to this:
- Client logs in (MongoDB)
- Client is at in-game home page w/ chat rooms (MySQL)
- Client goes to server list (MySQL)
Client connects to a server and plays in it
Server communicates updates for all players (MongoDB)
This is just the way I imagined it would work. Does this look good to you, or do you have suggestions on how this plan can be improved?