If you think it's not possible to develop a common protocol for different games – please, could you explain why exactly it's not possible? (besides basic "just all games are completely different" – as I wrote above, it's not true: there are lot of common things in terms of networking)

There are about four basic approaches that actually work. Those approaches are reasonably well known, but no one "bible" book describes them all.

The first approach is "spray and pray" -- just send commands as they happen from the client, and states as they update from the server, and let interpolation sort it out. Very simple, and can be effective for certain kinds of games. Drawback: Poor handling of player/player interactions.

The second approach is "lockstep synchronization" -- send commands for time X ahead of time to the server, which forwards to everyone else; the time step X isn't executed on all machines until they have all participants' commands for time X, then all the commands are executed in lock step; no actual state needs to be replicated as long as simulation is deterministic. Drawback: Long command latency before you see the action on the screen.

The third approach is "client ahead, remote entities behind" -- send commands for time X ahead of time to the server, and simulate them immediately on the client. Drawback: Remote entities are in a different place relative to you on your machine, compared to the server.

The fourth approach is "client ahead, remote entities forward extrapolated" -- same as the previous one, but forward extrapolate remote entities to approximate locations where they would be in the future. Drawback: May display remote entities in positions they will never be in, because they turn around instead of going forward or whatever.

Thanks you, this is exactly what I've asked for, just I've hoped there could be a strict specs for such things... but now I see it's unlikely, so will have to implement it from scratch and spend time to debug and so on and so on... That's why I don't really understand why there are no common protocols for such things – it could save a lot of gamedev time :-)

to talk to each other.

But you're right it's not a profit for those who developing such protocol. But it's a profit for a whole gamedev community, as any open-source things does. What could we made with Internet, if anyone develop own HTTP-like protocol for each site? (I understand it's not quite equal comparison, but still...)

Download Unreal Engine and use its system

Basically, I'm also looking for a hybrid way – to use UE4 networking and move all other server-side logic to my custom solutions, but it's an offtopic here.

The most "finished" library I know that is used in games is RakNet, I personaly prefered to roll my own simple just API level network service for TCP/UDP that works in Windows and Linux/Mac, Android using Socket and IOCP for few suers and massive users at the same time. Anything else depends on your game architecture. Everybody in every studio has its own prefered way to do and this may be also the reason why there isnt a general solution as you might seek for.

You need to decide what the server does, what the client does and how they work together. In most MMOs server does the gameplay and only tells client for the results, in other games there might be most processing power on the client side and server just evaluates stuff only and in some games server just spreads update messages only (Like in Dungeons and Dragons Daggerdale) what might result in asynchronously game states on each client where one client has had the intro already but another is still watching it, shops have different items for each player and such things

No need "to talk to each other", I'm just talking about re-using existing, already tested things for a most common part of any multiplayer game. But you're right it's not a profit for those who developing such protocol. But it's a profit for a whole gamedev community, as any open-source things does.

That being said, there exist open, well-tested libraries, and they are being used (Raknet has already been mentioned, enet would be another much less feature-rich example). Or, some just use TCP. Even that can work well (it really depends). Early versions of one particular successful MMO used unencrypted XML-RPC over TCP in the early 2000s. Yep, that worked fine for up to 1,500 connections per instance, don't ask me how they made it work!

Also, note that talking to the client isn't everything in a MMO. Usually (basically, always), the outward-facing machine(s) talking to clients are not the same phyiscal machines as the ones running the simulation, or the ones storing data, and often/usually "login" and "gameplay" are different machines, too. These servers need to talk with each other in some way. You might very well use something like zeromq/nanomsg for inter-server communication, for example.

In my time working on MMOs I've always been impressed at (a) how different the networking on each of them was, and (b) how much that was down to personal choice rather than accident.

For general object replication, my own code used a system much like the LESS protocol above, sent over TCP because it wasn't a fast-paced game. However one previous project completely refused to have automatically serialised properties because they wanted all updates to be explicit, and because their multi-server model required it. A 3rd project stuck to the ancient "one struct per message type, manually serialised" method because that's what they were comfortable with, and because their codebase was mature enough that they already had most of the message types they needed.

The prediction and interpolation layer was different on all three projects too, ranging from fully "client ahead, remote entities behind" on my code to extensive extrapolation and correction on another because they had to accommodate shooter-style gameplay with the same engine.

So actually, the stuff that the OP suggested was "the same, or, at least, very similar" was probably the area in which the networking differed the most.

I'm completely agreed that everyone has to implement own custom solutions for now. But it does not looks right way, since the issues are exactly the same for almost any game which you've described (I don't talking about personal preferences, just about technical issues).

Of course, in case if game has solid code base, it will not fit to any common protocol, but for a new game – I don't see a real reason why need to invent networking from the scratch every time.

Again, websites are all different, using multiple requests types, receiving and sending completely different data and so on, but all sites are using the same HTTP protocol.

So, for games, what's required, basically: low latency, optional errors handling, prediction/interpolation – and all this could be exactly the same for most of multiplayer games (not only MMO), technically.

You're talking that each game has made own solution – well, it's obvious, since we don't have a public one. They just don't have another choice.

I have pretty few experience with multiplayer networking, but maybe you can give me 2 examples of multiplayer games, which will be controversial to each other in terms of networking? (I'm talking not about existing games, rather about 2 design examples).

the issues are exactly the same for almost any game which you've described (I don't talking about personal preferences, just about technical issues).

No, they're not. The choices made regarding the game design and the technical constraints go hand in hand. Twitchy-shooters don't want to run over TCP with other clients shown at old locations. Slower RPG-type games will be fine with TCP and will prefer smooth movement of other clients with no corrections needed. Games where all you do is move and shoot will be highly optimised for low latency and resilient to dropped packets whereas games where the interactions with the world are more complex may be optimised for arbitrary messages and RPC mechanisms where everything is expected to be sent reliably and in-order.

Even 2 shooters can have different philosophies on how to handle interpolation or extrapolation. Some games focus on trying to be as perfectly synchronised as possible, at the expense of needing to perform more corrections. This might work well for eSports. Others happily rewind game state so that someone who already reached cover can be shot by someone who pulled the trigger when the target wasn't in cover yet, because the engine prefers a consistent experience for the shooter rather than the shootee.

You keep using HTTP as an example but it is a poor comparison. HTTP is designed as a standard for interoperability, not as a way to accelerate the development of web servers and clients. You choose to make a website that is served over HTTP because you want people with existing clients to access it, and because you can cope with the limitations of HTTP. And if you can't, that's why we have websockets, FTP, etc.