hello my friends.

im working on a mmo project and just started coding for network and data connection.

im looking for a method or way that is best for mmo games. the issues that needs to be solved is sending data for less times to have less traffic on the server. the next on is how to do it it will be hard to hack.

is this good for an mmo game to send and receive data synchronously or just game will happen on clients and after that they after some events like ending match just sending the data of match to server and database?

is this better to game be hybrid od booth of them or its better to implement most of game on clients and just for some events send data to server and in certain amount of time do some checkings of data base?

the the structure of game still is not comepeletly imlemented so hard to tell what going to happen in game. so even a general advice and exprince about these project in past can be good.

thanks for helping

Ahh, the infamous MMO.

You should read the links in the forum's FAQ.

Due to abuse of the term MMO, many modern developers have developed a more useful notation based on the number of concurrent connections. It is in the form C###, where C stands for "concurrent", and the number is the number of concurrent people. The term MMO was originally introduced for a C100K environment, that is, over 100,000 concurrent players. Most hobby developers struggle to build a server that can handle C64 or C100, which are 64 or 100 concurrent users.

For anything that is really "massively multiplayer", perhaps is on the magnitude of C10K or greater, you're mostly going to have a star where the individual clients talk to servers. The individual servers will also talk a lot amongst themselves to keep all the data coordinated.

More realistically for an individual who asks questions like that...

For an online game with a small number of players, perhaps C10 or C64 or C100 or whatever small number your servers will support, you will likely need a star for the servers to coordinate the players initially. Depending on your game you may be able to break small clusters of players off to their own little communication structure, or not.

Since you wrote about matches, individual sub-games and matches can often be released to the players where they run their own connections among themselves and don't rely on the main server for their tasks. Once the handshaking takes place many such games use a simple star by determining which player is best connected and selecting them as the match host. Some game networking libraries will automatically generate either a partial mesh using P2P bounces or a full interconnected mesh for you in cases where not everybody can reach a common host or in cases where some people communicate more slowly than others. Even more complex you can write code that migrates the host between machines when there are connectivity issues or players disconnect. That kind of code is a bit more complex to use and configure but can be quite robust when players drop. When the match is done the individual players report the results back to the game's main servers and rejoin the lobbies.

MMO design is a very intricate collaboration between available technology, art, story, and community assets.
Is it 2D/2.5D/3D?
How much is the focus on skill/die-roll versus action/fps gameplay elements?
How much simulated physics do you need for players? For environment?
How many players do you need to support in a single "area" (whatever that means in your game)?
What happens when more players want to go to the same area than are supported?
What level of lag are you prepared to accept for the player? For group members? For players that are just around? For NPCs? For the NPCs the player is currently fighting?
Is there PvP?
Is there player construction, or other environment modifications?
Will you need a single global world where anyone can meet anyone, or can players choose world instances ("servers" in WoW, EQ, etc)?
How much revenue do you intend to make per player per month? (This dictates what kind of resources you can put into it.)

If you are a small indie group with one or two programmers and three or four artists, you probably want to start somewhere simple, like with the "PyMMO" example, and grow from there as needed: http://www.enchantedage.com/pymmo

If I was to approach this problem myself, i would look at a acyclic spanning tree. All clients speak to servers in a star formation, and only relevant data for nearby players is sent to clients.

Servers talk to each other sharing only data which needs to be global, e.g. lists of usernames who are currently logged in to prevent multiple logins, and other pieces of important data such as which players have what on their inventory.

All servers should really talk to a highly redundant sql cluster on some really fast local boxes for data storage.

I did manage to get something good working like this before for my multiplayer role-playing game which scales to many more than hundreds of players per server (in benchmarking i had 8000 on it, but this isn't really representative of real player behaviour). It is based roughly on irc as a protocol, with asynchronous sql for a backing store and heavy caching. If you're interested in this, drop me a pm and i will be happy to share c++ source.

All servers should really talk to a highly redundant sql cluster on some really fast local boxes for data storage.

The option that most MMOs take is to design storage so that it doesn't need a high degree of throghput. For example, keep "game" state (hitpoint amount, affects, etc) in RAM, and only checkpoint back to a central store once in a while. Only things that need central authority and can't be lost (player trade, etc) needs to go directly through an app server and database.

Also, it's typically the case that there's a central "players" database, and then there's a separate "characters" database per world shard/instance. Almost all MMOs do it that way. The "player" database is only hit on login (to generate a ticket) and on subscription events (renew/cancel, etc.) The "character" server is the one that's hit for in-play characters, but as each shard is limited to the number of current players (because of area and gameplay,) there's an upper limit to what that server needs to be able to do.