12
\$\begingroup\$

My C++ turn-based game server (which uses database) does not stand against current average amount of clients (players), so I want to expand it to multiple (more then one) amount of computers and databases where all clients still will remain within single game world (servers will must communicate with each other and use multiple databases).

Is there some tutorials/books/common standards which explain how to do it in a best way?

Improve this question
\$\endgroup\$

5 Answers 5

Reset to default
8
\$\begingroup\$

The MMO terminology for "remain within a single game world" is single shard. EVE online is the only major MMO to attempt stuffing every player into a single shard.

Lucky for you they published a very informative article on how they do it.


(source: gamasutra.com)

The bad news. You cannot apply EVE online's techniques generally. Their solutions are absolutely tailored to their particular genre and implementation.
NOTE: For all of EVE online's super fancy single shard network they use one database. They were unable to design a scalable, consistent, moderately real-time solution for distributed databases.

Either way reading how they did it ought to help you design you ownr solution. Beware however, you are attempting to solve a very difficult problem.

Instead of distributing your game server I would suggest explore your other avenues first.

  • Profile your game server.
    • Optimize your server code to keep CPU burden down if that is a problem.
    • Optimize the communication protocol between the clients and the server to cut down on network chatter.
  • Optimize the gamer server to database communications.
    • run a query optimizer then make changes as appropriate.
    • cut down DB interaction to a bare minimum
  • Move the DB to a separate machine.
    This often helps a ton. Keep the DB on the same local network if possible but that ought to help your game server be a lot more peppy when it's the only thing running on the server hardware.
Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ How are you defining "major"? Kingdom of Loathing uses a single shard. Everyone shares the same Farmville shard. Star Trek Online and Champions Online both use a single-shard model, but instanced zones. \$\endgroup\$
    – user744
    Mar 7, 2011 at 11:25
  • 1
    \$\begingroup\$ Instead of using an SQL database, you could also use a noSQL solution which was designed for clustering and sharding, like MongoDB. \$\endgroup\$
    – Philipp
    Jan 30, 2013 at 18:18
  • 1
    \$\begingroup\$ @JoeWreschnig webgames aren't real time games, much easier... I'm not sure how many players do Star Trek Online and Champions Online have... \$\endgroup\$
    – o0'.
    Jan 30, 2013 at 20:38
4
\$\begingroup\$

Your first move should be decoupling direct database access from the game server and using a usage specific middleware to prepare data for your server (ie. XML, JSON). These would be able to handle any number of databases and more importantly be able to provide you with application specific caching options. Cache whatever you can and nag the db only when you must. Make big fetches and rarely instead of many small queries to achieve the best possible performance in your scenario.

The database of your choice might also allow you to operate clusters which make it easy to expand on the available database resources and provide your results faster, but this is a subject that needs much experience and a dedicated database administrator to set up and maintain - and not quite for the indie budget either.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ This all sounds fine until you consider that he's hoping to have multiple servers accessing one data set - this means that without further coordination, application-side caches will get out of sync leading to game errors at best and data loss at worst. I don't disagree with anything you've said but the original poster will need to also consider the cross-server consistency issue before proceeding. \$\endgroup\$
    – Kylotan
    Mar 5, 2011 at 18:24
  • \$\begingroup\$ The middleware is a data tunnel that is on one hand responsible for caching data, and also for providing data. However, it only provides data to the server (never to the client) and the server caches all game related master data at startup. So there can be many data sources and many data requesters connected at any time. The MMO I work on uses this scheme rather efficiently. \$\endgroup\$
    – Konrad K.
    Mar 5, 2011 at 23:26
  • \$\begingroup\$ That doesn't explain how you solved cross-server consistency issues at all. At some point the servers need to synchronize data between each other, or you have race conditions, which manifests as random disconnects, duplicate players, duped items, missing quests, etc. \$\endgroup\$
    – user744
    Mar 7, 2011 at 11:27
  • \$\begingroup\$ Data is never duplicated - at all times there is only one server be in charge of a certain object, and when required, it passes that object over to another server. Objects are client connections that also include the player control object. However, this is done via a master server and is debated between servers. So we're dealing with two kinds of data - database inforation (to which my original post relates) and game objects that are created at runtime and get passed around in a multi-server mmo. Neither of these should ever fall into a race condition or be duplicated on the application level. \$\endgroup\$
    – Konrad K.
    Mar 7, 2011 at 14:21
4
\$\begingroup\$

Regarding the game server: A common strategy is to use multiple servers where each server manages a part of the game world. Each user usually only needs to know about what's happening around it, so it makes sense to divide the world by locality. This unfortunately gets a lot more complicated when you have an open world without any borders instead of a world which consists of closed zones and players teleport between them. When you have an open world, you need a way to transfer players between zones in a seamless way and a way to synchronize the areas near the borders between the servers. That's a tricky problem.

Regarding the database: SQL databases usually scale badly. They are not designed for being distributed. But there is currently a rather new trend of NoSQL databases like MongoDB or Cassandra which were designed to be distributed over multiple servers. They make it much easier to add capacity by just adding more servers. So why don't all the large games switch to them? Because:

  1. SQL databases exist for over 40 years, those NoSQL databases only for a few years. There isn't much know-how yet how to use them most efficiently and their development is advancing rapidly. There are a lot of competing and completely incompatible products on the market, and there is no sign which of them will survive and which will be obsolete and discontinued in a few years. Most of the big players prefer the known shortcomings of SQL over the unknown risks of NoSQL databases.
  2. They work very differently from SQL databases and require to rethink your whole persistence strategy. This might result in drastic changes throughout your whole software architecture.

So when your project is already very advances, switching to another database solution might be a large risk and a very big investment of time and energy.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

No. This is an incredibly difficult area that has not been solved yet.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ May be there some "template" (not as "C++ design patterns) solution of it? There are plenty of MMORPGs. \$\endgroup\$
    – Slaus
    Mar 5, 2011 at 10:28
  • 2
    \$\begingroup\$ Most MMOs are backed by absolute disasters for databases. \$\endgroup\$
    – user744
    Mar 5, 2011 at 11:39
  • \$\begingroup\$ In particular, MMOs often have very different approaches to their data persistence, which often work acceptably for their own game design but not for other game designs. Since the game design is the most important part, you can't adequately specify a data persistence and distribution strategy without one. (Which could be construed as: "Ask a more specific question, telling us what sort of data you have, how often it changes, and why you think you want to distribute a single world across multiple servers.") \$\endgroup\$
    – Kylotan
    Mar 5, 2011 at 18:22
0
\$\begingroup\$

I know this is old but ....

There are actually two areas to focus on with this.

You need to distribute your application across several servers. You need to distribute your database across several servers.

And you need to have redundancy for both.

There are some open source solutions for this. Farmville is a good example using MemSQL / Couchbase.

Improve this answer
\$\endgroup\$
1
  • 1
    \$\begingroup\$ Distributing the database across multiple servers is certainly a solved problem. Unfortunately it's not usually an important requirement for online games which keep their DB accesses to a minimum. By contrast, distributing the actual gameplay across multiple servers is still not a solved problem. \$\endgroup\$
    – Kylotan
    Jan 30, 2013 at 18:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .