But they also got an interesting GDC talk out of the effort, so it wasn't a total loss :-)

Thanks for the replies, they were really helpful.

In summary, using of postgres with json column sounds good - so I can skip using of MongoDB - and I plan on modifying my study to be more like "high level thing" than "game details specific", the reason for this is that like you mentioned that the final architecture will emerge from the game design -- which is most likely true -- but I don't have room nor time for making detailed e.g. "20 pages GDD" within the study and evaluate it. However, I won't go too high in a way that there is no way to validate anything in a reasonable manner (hey, this is "yet another client-server architecture you can build anything upon" ... mmkay?). Hence, part the of study is to build/evaluate in practice so that is something I am planning to do. Luckily there is a lot to learn from that. But yea, thanks again for the help! :cool:

I'm going to skip over all the other advice given here and impart my own, based on real world experience as much as anyone else's.

You can take my advice along side, or exclusive to, all the other recommendations here.

About ten years ago I created a Web browser based multiplayer game which at its peak had about 1400 active players. Not enough to call it an mmo, but a reasonable amount.

The game had two parts, a front end and a back end.

The front end was the game proper which had authentication, registration, and gameplay and chat components, and the backend was an admin area.

In the backend it was possible to create and edit game locations, add loot, npcs, design the game basically without technical knowledge and manage users. Generally this came down to password reset, emails changes, checking for multi accounts using edit distance etc.

Also in the backend it was possible to promote a player to a DM, which gave them abilities to teleport, become invincible etc, all for testing and support.

All of those features were backed by an audit log.

The game was written in C++ as a set of fastcgi programs for apache 2.0, backed by a MySQL database and using the native MySQL api.

The game also had a facility to report problems either with the game itself or with other players, this was extremely important to combat griefing and trolling.

Chats were logged for the same reasons.

There's a lot more I could tell you, if you want to know anything specific please ask!

I'll even share code if you like but I warn you, it's not nice stuff (lugaru is neater) and I wouldn't approach the same problem with ther same solution today if I stated again.

Hope this helps!

Thanks braindigitalis, it was interesting read. :)

I think I have started to see some patterns here regarding the requirements - which is good. Also, I forgot to mention earlier that my plan is not to do detailed explanation of client-side things, because I am mostly interested in documenting the server-side parts. For this reason, things like "client-side prediction" are outside the scope of my study and how / what should be predicted is really game dependent anyway. Nevertheless, I like the information already provided here and I think I have enough for now. Thus, my C++ skills are too poor to interpret your awesome code. But thanks for the offer. :D