First off I will just say that I have been programming for years and I am very familiar with sockets and multiplexing/async network io.

However, I have not done any game server programming and that I what I need to focus on for my project.

This will be for developing a large scale game server (like for a 3d MMO). It is also important to note that I will not be using an existing game server like unity, etc. This will be from scratch.

I need to know things like:

• Architecture(s)
• common issues to look out for
• best practices
• common components of a game server (sync server, chat server, etc)

I can fill in any gaps that I have. I just need to know all the moving parts.

Thanks ~ mullagain

Hi. no pro here but some things for thought.

You will be needing a Database for client data, logon, password Alias name, thing like that. You will need a Good database key for each reacord for fast finding of client logon info.

What protocol you want to use TCP, UDP, some other.

Encryption RSA Private and Public Key encryption for password sending.

You will need to sign each data packet or thing sent over your connection for validation.

You will need to monitor network for DOS attacks and things(TimeAttacks).

You will need to maintain the servers integrity dueing an attack its all you can do.

Have a Banned List.

Time stamp your clients database records so you can remove long idel accounts.

You will need a file transfer mechanism.

Some things I'm currently using

Boost::asio base networking

boost lockfree queue sacrifice memory for efficiency (have your self a real time message system good for robots)Send and Recieve Queue's

Design your server so it could take advantage of having a pool of servers connected

GoogleProtocol buffers for serialization of messages

Zlib for compression

Cryptopp for encryption

I set up a 2 key pair system 1 key pair is for password encryption the other is a smaller key but safe for signing the packets

SQLite for data base

So far time spent on the above server is. Started on this date 3.2.15 and it is now 13.8.15 wow been that long this is part time but also have spent some long hours in it.

Im at the stage where clients can create account edit them, Join Create rooms(games) and send and recieve map file, And start and a game to the point that it loads up.

Thanks for the info. I am familiar with what you are talking about (more or less). I am more curious on architecture. If a game has 100,000 players connected obviously one database instance cannot support that, much less the tcp/udp stack on the system.

I come from an enterprise environment and I am curious how people have implemented shared nothing for gaming.

As an enterprise developer myself it's way different.

Basically you have many application servers handling the state of the game, and you only save information that changed once it must absolutely be saved. For example, Unlike in business dev where we load everything from the DB, you need to pack as much as possible on the client to reduce load, and verify the client's integrity with the application servers if needed.

It really depends on the kind of game. But, here's the "archetypical" architecture for an MMO game with player interaction and server-side rules enforcement:

A "typical" MMO "RPG" shards the world into "zones" where each "zone" is some physical area, with some kind of transition between them for a traveling player. The size and gameplay of each area is designed such that the maximum number of players in that area does not exceed the throughput available for a single server (typically SMP, in-core, shared state multiprocessing.) More complex game rules and more complex simulation/physics will reduce the number of players that can be in a zone, and/or increase the size of machine provisioned for that zone (and there is an upper limit to that size.)

"Instanced dungeons" are a gameplay design feature that helps with this, because each instance is sized to perhaps 10-50 players, which means it can fit on a smaller (virtual) server host, and load can be more homogenized. Some games also auto-instance the same world zone for the same world instance more than once -- City of Heroes did this for high load areas, for example. You'd have "Main Plaza #1," "Main Plaza #2," ...

Worlds, in turn, are horizontally sharded into what players see as "servers." So, if I play on the "Brlaghadepr" server in some MMO, that's really a set of character-database-plus-zone-instance-servers. There's a separate subscriber-database which actually contains all subscribers; this is typically sharded horizontally by customer ID or somesuch, but that database is only required for initial login, and for account status (banning, subscription, etc.)

Game state is largely kept in memory in the game servers, not in databases. Game servers checkpoint important state back to character databases on a periodic basis, as well as for things that have to be transactional (like player/player trade of valuable items.) Optimizing the CPU and RAM usage of the game servers is important to manage costs, and allow large crowds of players in the same virtual game-space.

Clients are either made to re-connect to different world instance zone instance servers as they move around the world, or there's a load balanced "gateway" role at the edge of the network, where the client talks to the gateway, and the gateway just knows how to forward client traffic to the appropriate server instances.


If you're building an MMOFPS, this architecture changes slightly. If you're building a game with player-hosted game instances, the architecture changes more. If you're building an asynchronously multiplayer game, like Farmville, the architecture changes drastically.
Because of the actual, palpable, benefits to gameplay from CPU and RAM usage optimization, each architecture tends to specialize for the particular game being implemented. Thus, there aren't really any two games that would be as well served by some generic architecture "platform" or "fabric" or "substrate" (other than "utility computing" like ECC/Linode/Rackspace/etc.) This is a requirement that is quite different from enterprise data, and enterprise people who don't understand this invariable end up failing.