12
\$\begingroup\$

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:

  1. Client logs in (MongoDB)
  2. Client is at in-game home page w/ chat rooms (MySQL)
  3. Client goes to server list (MySQL)

  4. Client connects to a server and plays in it

  5. 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?

Improve this question
\$\endgroup\$
8
  • 9
    \$\begingroup\$ At least you've provided plenty of information, unlike some people who don't give enough information. \$\endgroup\$ – Cyclops Aug 23 '11 at 12:27
  • 7
    \$\begingroup\$ I may be misunderstanding what you are suggesting, but as a matter of security, your game shouldn't be connecting directly to your database anyway, so connection count shouldn't matter. If your game can connect, then so can anyone else. You also probably shouldn't be opening a new connection from your game server to the database for every player who connects. \$\endgroup\$ – Matthew Scharley Aug 23 '11 at 12:57
  • 1
    \$\begingroup\$ What language/tools do you plan on using for the back end programming? \$\endgroup\$ – aaaaaaaaaaaa Aug 23 '11 at 13:18
  • 4
    \$\begingroup\$ If you choose a hosted DB you'll have a round-trip from your game to your server and from there to the DB server. This is going to be slower than from game to your server (which opens a local DB connection) and will nullify the assumed performance-gain of using NoSQL. \$\endgroup\$ – bummzack Aug 23 '11 at 16:23
  • \$\begingroup\$ "team has a shared webhosting package that offers unlimited mySQL storage and bandwidth"... What they tell you and what you get are two different things. You can "have" all the space in the world but if you're accessing it through a virtual straw instead of a fat pipe then it's useless. \$\endgroup\$ – Ken Aug 23 '11 at 16:35
12
\$\begingroup\$

My suggestion is to have your game communicate to a web service that you created that itself deals with querying the database. At that point, it's very simple to try different kinds of databases by "switching" web service implementations (your web service interface always stays the same so your game doesn't break) and decide which one is right for you.

It's also a lot more secure to not expose your database to the internet directly.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ That's a great idea, thank you, I definitely will. I'm new to using databases, so these things haven't occurred to me. \$\endgroup\$ – Andrew Aug 23 '11 at 23:50
  • 3
    \$\begingroup\$ +1 Having client communicate with DB directly is a security hole of the goatse.cx caliber. \$\endgroup\$ – Nevermind Aug 24 '11 at 6:19
7
\$\begingroup\$

we can only have 25 connections open at one time (shared hosting rule).

That's more than enough for your game. The problem is that if your website uses multiple connections, you could run out. You need to configure your web server to only use a small number of them, leaving the rest for your game server. Your game server doesn't really need more than 1 connection, but might benefit from having a handful.

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.

It's a bit of a false argument, because neither system is fast enough to use as the main store for a fast-paced realtime game - you really need to keep and manipulate the values in memory. So you only hit the database when you absolutely have to, which might just be to save the whole character every so often (eg. once a minute), at which point the speed differences become negligible.

The funny thing is, if you tweak MongoDB for top speed, you can just about get it to a point where it would be fast enough for you to perform synchronous writes from within a reasonably fast-paced game, but this would be at the cost of data integrity because the writes are buffered. This means you lose that data in the event of a crash, so there was little point performing the write at all, and it's still slower than if you just performed the edit in memory and saved it later, so you get the worst of both worlds.

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.)

Ask yourself why you need to write to the database when a player fires a gun. Why can't that just be handled in-memory on the game server? If your game crashes, and later restarts, and the player finds out they have 3 bullets more than they expected to have, is that a critical business problem?

I also like the straight forward schema-free documents (which make it easier to map game object data).

This is a much better reason to choose a NOSQL approach than the performance issue.

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).

That's fine, and sensible. Later on you might want to use a separate instance, so that web reads aren't contesting with game reads and writes, but that problem is a trivial one to solve compared to the problem of getting popular enough for this to be a problem.

Personally I would just pick one of the two databases, based on which one would be less work for me, and standardise on that - but there's no reason you can't keep with two if you like.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Can you suggest any framework for this ? "you really need to keep and manipulate the values in memory." I have heard of redis, but its just key value relationship, is there something where we can manipulate? \$\endgroup\$ – user1735921 Oct 26 '17 at 13:06
  • 1
    \$\begingroup\$ No, when I say "keep and manipulate values in memory" I am literally just saying "the game runs like a normal program with the data stored in variables", not as some sort of special database layer or framework. \$\endgroup\$ – Kylotan Oct 28 '17 at 13:42
5
\$\begingroup\$

All the real time data needs to be kept in application memory, anything else would be silly.

Keeping users login data, stats etc. is a pretty light task, so I'll be bold and say that you can use pretty much whatever you want. Though you might want to be careful with the website, stuff like user lists could suck up a lot of database performance if you don't make a proper caching system.

And like bummzack said, you should keep everything in the same network. On top of that, beware about free stuff, 240 MB free database storage sounds good, but since the machine is probably split between a large number of free users service could be pretty slow.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ I agree, you want ot keep your game data in memory, and you may as well keep login data in memory as well (considering that they are MUCH SMALLER) \$\endgroup\$ – MarkR Oct 16 '11 at 6:26
  • \$\begingroup\$ The reason for not keeping some data in memory (or letting a database handle that it is both in memory and on disk) is that you want the data to be persistent if the server crash. Easiest way of securing that is to store it in a database. \$\endgroup\$ – aaaaaaaaaaaa Oct 16 '11 at 8:37
  • \$\begingroup\$ You can still use a database for persistence - but still keep the data in memory, that way you have robust crash-safe storage, but access which is fast enough not to block the server (from other activities) if you need to verify logins etc. \$\endgroup\$ – MarkR Oct 16 '11 at 12:02
2
\$\begingroup\$

Do you trust your 60,000 users per database? If not, you should nix the "database access from the client" idea, unless your level of expertise in the security of the database software is top-notch, and you are confident that you can accommodate any issues that result.

Improve this answer
\$\endgroup\$
1
  • 9
    \$\begingroup\$ And if you are confident about that, then ipso facto your level of expertise in database security is not top-notch. \$\endgroup\$ – jhocking Aug 23 '11 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.