I have been working on a mobile MMO type game - If you are thinking of GW or WoW, stop. This project is not and never will be even approaching that scale. This game is fairly limited in scope and is not a giant universe of things that would be appropriate for a large studio. Specifically, I have been trying to sort out what type of database would be appropriate. I have read posts and opinions on this topic ad nauseam. There is a team of programmers working on this project, but none of us have had any experience with NoSQL type databases. To be clear, I am not saying that we should be using a NoSQL database, but I am saying I want to study our options. So here are the details of my project.

Let's assume...

1. The project's scope is within the team's ability to complete it in a reasonable amount of time.

2. We will get to a large number of users, 10,000 concurrent, 100,000 total (relevant to rough size and activity of database - I realize there is far more to it, but work with me here)

3. The general server side architecture is authoritative in nature to discourage cheating, which means there will be a fair amount of database load per player.

4. No character walking around a large world - No location type data to be stored.

Database needs to store...

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

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

3. Many time based events.

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

Thoughts?

4. Large number of players (well say 100,000)

Wow, 100,000 players, really? That's impressive. How many of them will be playing simultaneously? Because, you might have to implement some sort of sharding or similar load balancing system, and mirroring databases across all the nodes is an art form in itself.

But anyway, many online games use several different types of databases for storing persistent data. For example, if you have data that naturally fits in a table with the same columns then a good ol' SQL database is probably the best choice, eg. postgreSQL is known to be reliable and performant. For data where the structure varies more some sort of no-SQL database might be a better option, eg. mongoDB.

Also note that you will most likely have lots of logging and auditing data generated by the game, ie. data that is not strictly speaking required for the game to run but allows you to more easily debug and develop the game. This kind of data is usually stored in a different database than the actual game state data.

I'm all in MySQL, it has a number of different engines: The most common are INNODB and MYISAM (I can't recall which one was what) and the difference is huge (and you can choose which table uses what). Both of which are implementations of the "new ways" and the "old ways" (I hate this misnomer).Transactional and atomic queries are the nice thing about the "old ways"... the "new ways" can corrupt data if done incorrectly (well, maybe it's unavoidable).
The thing is that you talk about 100k users. And a MMO. While making tests you will realize that you will step over unless you really know each step towards making that... and it might take a lifetime.

Specifically, I have trying to sort out what type of database would be appropriate.

The fact that you don't know is a good sign you are not ready for a game at this scale.

I am guessing the type of data base is one of the smaller problems that you have. In the end, all data bases are mostly the same, they store large quantities of records with data.

While there are no doubt performance differences at full scale, it won't make any difference now.

Just pick one. It's likely to be wrong, but replacing it with something better shouldn't be a major problem, as their interface is all similar.

Have you done any studies on what happens if you have 100,000 live network connections? As in, how much traffic does that give, at the computer side, how many network packets / second do you have to handle, how many of those need data base access, so how much time do you have for one DB query? How does that requirement match with whatever data base you have?

At the network side, how many network packets does that cause, how fast must your network connection be, what does that cost?

Inside the data base, how many records will you have, how fast does performance go down as the number of records goes up, etc?

Sort of a "big data stream picture" to get an idea how much iron you'll need for that scale.

https://www.gamedev.net/blog/355/entry-2250155-why-you-shouldnt-be-making-an-mmo/

Not really relevant for the OP here. He isn't talking about the traditional kind of MMO such as GW that is mentioned in the article but a Mobile MMO which is less of an MMO game and more of just a multi user database with a pretty GUI. Turn based, very limited amount of content. No need for a massive development team. Fairly small amount of assets, No real user customization, Networking is usually just a REST API over HTTP. There are literally hundreds of these being released on iOS and Android every week.


Sure 100,000 users is a bit ambitious but, with modern tools and cloud infrastructure its fairly easy to optimise and scale up when needed. OP could probably pull of a MVP just using Firebase or Parse Server.

1. No character walking around a large world. 2. The world for a player consists of a limited view of their game. Think Clash of Clans. 3. Game objects have varying levels of progression. 4. Large number of players (well say 100,000) 5. Inventory of a mixture of roughly 200 items 6. Many time based events

OP could probably pull of a MVP just using Firebase or Parse Server.

Sorry, but as this is For Beginners, adding some realism to the dream is (unfortunately) probably the best idea. The journey can be fruitful, and the person can learn quite a lot attempting to reach that goal, but encouraging an unrealistic goal isn't very kind.

While part of the question is about databases, the entire situation is entirely unrealistic. Even using great tools, a game at the scale being described cannot reasonably be implemented by a single human, particularly a beginning developer.

It is important to understand that the dream cannot be achieved by one-self nor with a small group of beginner friends. A large team of experts can accomplish it, certainly, but that isn't what they have.

Helping to redirect the goal into something more realistic can be fruitful, and that's what a few people have done.

But getting back to the original question:

I have trying to sort out what type of database would be appropriate. I have read posts and opinions on this topic ad nauseam.

Deciding what tools and technology to use -- including databases -- is mostly an exercise in elimination.

Make a list of all the possible software you want to use. Eliminate those outside your cost range. Eliminate those that have known problems you cannot work around. Eliminate those you know or believe you cannot work with, although leave them if your choices are limited and you can potentially work around the issues.

When you are done eliminating the ones that will not work, you should have a pool of those that might work. Pick one, either at random or because you have familiarity with it already.

If you ever discover the tool won't work, add that to your criteria, eliminate all those that fail the new test, and pick from among the contenders again.

At this point you have quite a few excellent free database systems to choose from. Study them a little bit, study your needs, and pick one. Pick from the list at random if you must.

While part of the question is about databases, the entire situation is entirely unrealistic. Even using great tools, a game at the scale being described cannot reasonably be implemented by a single human, particularly a beginning developer. It is important to understand that the dream cannot be achieved by one-self nor with a small group of beginner friends. A large team of experts can accomplish it, certainly, but that isn't what they have.

There are several MMOS that have been developed by one man teams recently:

Agar.io

Slither.io

Sherwood Dungeon

Love

Minecraft

Some of the developers probably have more experience than others (Notch obviously). Others though whilst having experience in software development in general, do seem to beginners at games development.

Besides the OP never indicated weather he was developing by himself or with others.

I have been working on a mobile MMO type game. Specifically, I have trying to sort out what type of database would be appropriate. I have read posts and opinions on this topic ad nauseam. The main issue I am having is that most are working on games that are not in the same vein and thus I cannot tell how relevant the opinions would be to me. So here are the details of my project.

1. No character walking around a large world.

2. The world for a player consists of a limited view of their game. Think Clash of Clans.

3. Game objects have varying levels of progression.

4. Large number of players (well say 100,000. Notice: I DON'T MEAN CONCURRENT)

5. Inventory of a mixture of roughly 200 items

6. Many time based events

Thoughts?

None of that tells us anything about what you want to actually store. Therefore there's nothing we can suggest regarding which database to use, as it's not even clear that you need one.

Lacking any further information, the best answer is probably Postgresql.

If you have an idea of what needs to actually be persisted to the database, based on your game's requirements, we can come up with a more directed solution (which may still be Postgresql, but anyway).

There are several MMOS that have been developed by one man teams recently: Agar.io, Slither.io, Sherwood Dungeon, Love, Minecraft

I hate derailing the topic this much, but here goes a little:

That first "M" in "Massively Multilpayer Online" means something. Multiplayer games can commonly handle a few hundred players. If interactions are limited they can sometimes handle into the thousands of players. The term "massively multiplayer", was originally used for games with over 100,000 concurrent players, and inside the industry generally means even more than that. An online game with hundreds or even thousands of players is not "massive". Even a multiplayer game with hundreds or thousands is not "massive". When it approaches or exceeds six figures of concurrent players -- not in lobbies that go to small games, but actually large groups together -- then it becomes an MMO.

Slither.io. Started as a one-man gig. A game could handle up to about 200 concurrent players before they became unplayable. The one-man developer became a multi-developer team, rewriting the servers to handle 500 concurrent players. MO, but not MMO.

Agar.io. The first version was by one individual. Then he started working with Miniclip, rebuilding the game and expanding it considerably. Even so, a map can have 128 concurrent players, so hardly MMO. Yes they have a high total player count, but they are all independent from each other and certainly not in the hundreds of thousands in the same world. Many thousands in the lobby, but that's different and an enormous number of products can boast of that feat. That is branding and player count in parallel multiplayer games, not concurrent players together in a massively multiplayer environment.

Sherwood Dungeon. Like the others, started out as a small online game by a single developer, and based on blogs and the wikia site his original system did scale rather well to about 4000 concurrent players. He was also an industry veteran. Looking it up online, he started around 2004 as a hobby, and slowly started growing it by himself. He quit his day job in 2006. By 2008 there was another worker, his wife. Soon there were "other respective parties", and everything shifting from "I" to "we" around 2010. Early 2015 he announced plans for a mobile edition that still doesn't exist, and a year ago the developer said he's getting a job as a regular programmer in another game studio. So it was a large-sized multiplayer online game, but never approached massively multiplayer scale.

And Minecraft. Notch made the first versions by himself, and if you played it from 2009 to 2010 it was by himself. If you joined in during the initial Alpha version you were looking at a roughly 10-person team. The credits listed in 2011, the "prerelease 1.9" version had 16 people. By the time they reached "beta" they'd hired and brought in double that many people again, and various people at the rapidly-growing company said they nearly rewrote the entire rendering system and most of the networking system, and they completely replaced everything on the server side. It had grown to roughly a hundred when Microsoft bought it in 2014, and with all the ports the total developer count is much more. The Minecraft you have played for the past four years had over a thousand work-years on it, far more than a single developer could do in ten lifetimes.

YES, an individual developer can build a game in the spirit of something larger, and with the goals of it becoming large. That is encouraged. Over in the Multiplayer and Network Forum FAQ are some documents where various people -- including that forum's moderator -- build MOG's quickly, including a small game server built in about four hours of work in Python. It could likely handle several hundred players, maybe even a few thousand concurrent players. A few people leveraged similar systems to put together full-fledged MOG's in about a week, no problem if you keep it minimal and know what you are doing. There have been Multiplayer Online Games since the 1970s, then called MUD (Multi-User Dungeon) and MUSH (a more social variant) games, and they are entirely within a single developer's scope.

NO, an individual developer does not have the capacity to build an MMO, in the real meaning of Massively Multiplayer Online Game, because even the most powerful off-the-shelf tools cannot handle it without a large team of experts and an enormous pool of money.

And trying to stay on topic as best we can, for a regular online game, the data that would be placed in a database can likely use any database system. Some designs may lend themselves slightly toward different solutions, but any of them should work in general. If a person has a specific reason to exclude one it should be excluded, but likely any of them would work.