In an effort to steer the thread back on topic... The choice of SQL-like vs NoSQL database typically has very little to do with the size or quantity of data, and a lot to do with whether or not you need transactional semantics.

In essence whether you need transactions boils down to whether it is important that everyone can be guaranteed to agree on the values in the database at all times. For a global item attribute that is only updated when you release a new version, the answer is most likely no. When two players are actively trading items/gold, the answer is definitely yes (i.e. if one player unplugs their ethernet cable in the middle of the trade, is it important to know who ends up with the items?).

In a practical modern setting, you will likely want three types of database-like systems in your game:

• A cheap, high-performance NoSQL database to store shared data like item attributes and descriptions, location data, etc.
• A transactional database (likely SQL-like) to store player gold, inventories, and maybe things like quest progress.
• And an in-memory caching layer to sit in front of the above and improve read-throughput (i.e. redis or memcached).

(there is also the question of whether you need rich queries/joins, but that's probably less relevant to that game itself than it is to metrics and analytics used to analyse the game's performance and operation)

@swiftcoder: Having 2 data bases, with memory caching, all connected together, is something we should recommend to a beginner? Say, right after "hello world" and MyFirstClass()?

@bluebass44: Please don't silently edit the first post, it gets missed. Also, it is hard to track what exactly you changed. Better post an update instead.

As for the question, I very much don't agree with your first assumption, but if you like close contact with big walls, nothing beats your own experiments.

Stuff is sufficiently complicated to throw random surprises at you, and you cannot select a data base based on answers from a single post of 10 globally descriptive sentences. The answer is try things. Get list of candidates, build an experiment for each of them, and throw a realistic load at it, and watch what happens.

For extra fun, build the network layer too.

Those things are sort of the core of the application, so that has to survive a huge load.

Given the stealth update to the OP, I'll throw in some more data:

1. Many game objects that have varying levels of progression - not every player possesses the same objects (This is what makes me begin to wonder about NoSQL).

There's nothing intrinsic to NoSQL here. This is fine for a relational DB. You'll probably have item data in standard DB tables.

2. Inventory of a mixture of roughly 200 items and associated quantities.

If these are instances of the items above, that data might also be suited to a relational database. Or maybe it could be a document in a NoSQL DB. Or it could just be a blob on disk. Whatever you like. Any database can handle this.

3. Many time based events.

I'm not seeing the word "data" here. Not a database issue.

4. A large number of player to player transactions - think the stock market.

Any database can handle this. That's what they do. If there's real money involved then you probably want to use a standard relational DB just so you can be sure about atomicity of transactions. But if you're just talking about item trading or whatever then that is not a big deal. It's more common just to do that in memory and use the DB as a backing store for the player saves. Save both players at the same time for better consistency.

Rule one of coding: constraints. What are your constraints?

Although brushing over this in a realistic way for most developers I'd say to KISS, just use mysql or some other kind of military grade database. It's often borderline impossible to predetermine how something will operate in a high stress environment in much the same way you can't figure out if your code will run fast without profiling it. You can make guesses, try to structure data and save/load methodology to make it efficient, but we're not gonna be able to throw out some magic number "Oh if you have 100k players you need XSQL and will need it in this format and saving this often." That doesn't exist.

On the off topic note: I don't get what people's obsession is with classifying it as MMORPGS(WoW, TSW, Eve, Wildstar, FFXIII, etc.) and "everything else" ORPG? I don't know. Usually when I talk to people about multiplayer games the term ORPG is useless and doesn't at all convey the wish for people to create a persistant game. I often see people go on a rant on here about how "THIS ISN'T AN MMORPG, AN MMO MUST BE MASSIVE!" to me that's utterly pedantic. A lot of the games we have long called MMORPGs like runescape or even ultima started off with very small amounts of people, often they only support small amounts of people and are just sharded to support insane numbers of people across insane numbers of servers. A lot of people seem to forget that many MMOS grow organically and don't start off supporting a million players. The MMO part is usually related to the type of game that is being created rather than the number of people on it.

On the off topic note: I don't get what people's obsession is with classifying it as MMORPGS(WoW, TSW, Eve, Wildstar, FFXIII, etc.) and "everything else" ORPG? I don't know. Usually when I talk to people about multiplayer games the term ORPG is useless and doesn't at all convey the wish for people to create a persistant game. I often see people go on a rant on here about how "THIS ISN'T AN MMORPG, AN MMO MUST BE MASSIVE!" to me that's utterly pedantic. A lot of the games we have long called MMORPGs like runescape or even ultima started off with very small amounts of people, often they only support small amounts of people and are just sharded to support insane numbers of people across insane numbers of servers. A lot of people seem to forget that many MMOS grow organically and don't start off supporting a million players. The MMO part is usually related to the type of game that is being created rather than the number of people on it.

FFXIII is a single-player game. I think you mean FFXIV.

It might be pedantic to you, that doesn't mean it's not a valid distinction for a lot of other people. Especially among developers, it's very common to use either different terminology, or terminology in a different manner than how consumers use it.

Terminology matters in communication, because it conveys a set of problems, solutions, and constraints.

Another important aspect is terminology changes over time. A concurrent user amount of x could be classified as massively multiplayer before, but not now. Just like a game that looked jaw-droppingly amazing 20 years ago would most likely not be perceived as all too amazing with the current visual standards.

Let's say I'm making a racing game, that is only viewed from the point of view of the driver. If I need to discuss it or find solutions to the technical side of things, do you think it's better for me to search for "First Person game" or "Racing game"? Stick a gun on the car and I could argue all day that I'm making a FPS game, but that doesn't help me one iota if I need to ask for help on car steering mechanics, friction and realistic engine sounds.

If what people/developers are actually asking questions about persistents worlds, then there is terminology for that, which you already used -- persistent.

MMO -- Massively Multiplayer Online -- conveys a problem set that includes a ridiculous amount of concurrent users, and all the follow-on effects of that. The solutions to those problems are, at this point, fairly well known, as is their cost: "very very very expensive".

A persistent online game, on the other hand, is a different beast altogether. Especially if it also comes with a estimate of concurrent users, and other important aspects.

I often see people go on a rant on here about how "THIS ISN'T AN MMORPG, AN MMO MUST BE MASSIVE!" to me that's utterly pedantic. A lot of the games we have long called MMORPGs like runescape or even ultima started off with very small amounts of people

I guess the issue is that it's important to know just what sort of scale we're talking about, because there are certain changes that can't really be made organically without massive upheaval. Ultima Online was certainly made with these large populations in mind (and pretty much invented the term 'sharding' for the way it approached the problem). Ironically, the (Western-made) game with probably the highest concurrency, World of Warcraft, is one of the most primitive in terms of having relatively few people per server.

Obviously there are some things that are common to "persistent online game" (RPG or otherwise), but there are things that vary based on the 'massiveness' (can I broadcast every update to everybody or do I need area of interest management? Can I service all players with one network adapter? Do I need to consider scaling horizontally? Can I keep all game data in memory?)

Apart from reality checks and practicality concerns, I think SwiftCoder is pointing right direction.

I think ideal setup would be

- A NoSQL database to store recent and relevant game data (if game data is tailored to benefit from document storage, therefore preferably no joins or aggregrated functions)

- A relational/NoSQL database to store logs, states and ancient data

- An in-memory solution such as Redis (Actually in theory Redis can be used mainDB although not a good idea, at least Redis makes your stack database-agnostic, theoretically you can use any DB behind)

But depending on how demanding game is and your player projection, you can even start with simple relational database. But in case like 10K concurrent player, it becomes a challenge out of scope of a beginner question that should be handled by professionals (who aren't including me :) )

I guess the issue is that it's important to know just what sort of scale we're talking about, because there are certain changes that can't really be made organically without massive upheaval.

That's my point though, some people are pushing "MMO" or "MMORPG" to be terms that mean literally something of the scale of the games I listed(and yes I meant FFXIV in my earlier post.) But most people, even a lot of developers I've met, will use MMO as a generic term for the kind of "large, usually persistent game." I don't think its a very descriptive term. Where do you draw the line? Facebook games? MUDs? Do we consider games like LOL to be MMOs because they have a large, complex background server architecture? Quite a lot of games have that. Heck a lot of mobile games would count as MMORPGs if we just go on that line of thinking, and that is an equally unhelpful basis for discussing the technical issues involved. A phone game won't have a lot of the issues that a WoW style game will have.

Ultima Online was certainly made with these large populations in mind (and pretty much invented the term 'sharding' for the way it approached the problem).

To be fair most MMOs start off generally small and end up being patched and improved over time to support the massive scale they usually fill.

Ironically, the (Western-made) game with probably the highest concurrency, World of Warcraft, is one of the most primitive in terms of having relatively few people per server.

WoW is another example of a game I think grew rather organically, I was there when it was released and the scale of people(and the back end servers likely) were much smaller, they redid a LOT of that game over the years, even before the expansions. But I mean.. putting it in perspective WoW was about as MMO as runescape was, they butchered the wc3 engine and turned it into an MMO.

Obviously there are some things that are common to "persistent online game" (RPG or otherwise), but there are things that vary based on the 'massiveness' (can I broadcast every update to everybody or do I need area of interest management? Can I service all players with one network adapter? Do I need to consider scaling horizontally? Can I keep all game data in memory?)

If anything all I've really thought writing these posts and reflecting on the issue is that games can have so many little pieces of each other that just blanketing them all under one technical term would never work. My main issue is how I often see us go off topic(like we are now) just to correct someone on "why you shouldn't be making an MMORPG instead of an ORPG" when instead the issue should be ascertaining what scale and specifics of a game they are talking about.
Although in this case I'd see the general response would be fine, that even making a small multiplayer online game can be very challenging.

Although in this case I'd see the general response would be fine, that even making a small multiplayer online game can be very challenging.

Even there you need to be more specific.

Is a multiplayer Facebook game played at the pace of actions-per-day (say, the long deceased Warbook) very challenging? Is a turn-based board/card game very challenging to make multiplayer?

I'd argue that most multiplayer games which you can implement using an off-the-shelf REST server are *not* very challenging. And off-the-shelf REST servers scale out to 10k concurrent users without even blinking.

But most people, even a lot of developers I've met, will use MMO as a generic term for the kind of "large, usually persistent game."

I've worked on MMOs, so I consider myself to have a slightly more useful definition of what it means than most people. That's not to say my definition is more correct, just more useful.

It's a useful term in that it gives you an idea of what people want to do. It's no worse than FPS, RPG, or any other term which may not fully capture all the requirements.

In this specific case, the OP said "If you are thinking of GW or WoW, stop. This project is not and never will be even approaching that scale." but goes on to say "10,000 concurrent" which is actually VERY large for a single server, if you're doing real-time simulation and broadcast rather than turn-based updates. (WoW, as I understand it, usually doesn't even approach 2/3rds of that in one world, and that world is both geographically partitioned and heavily instanced for dungeons.) So, as far as the "whoa, do you realise what you're getting in for?" aspect, I think some sort of "MMO-warning" is reasonable.