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)

Compare Overwatch (6 vs 6) or Titanfall, Battlefield, or anything similar to Anarchy Online (hundred vs hundred, and tens of thousands in the same world) or World of Warcraft (few vs few, but tens of thousands in the same world) on the other side. Compare any of these to any game similar to... Forge of Empires, or to any of the countless "build your own village" games.

Compare in each case what the total number of players are, what the numbers are in your immediate visible neighbourhood, compare how far you can see and how you can interact, and compare how responsive the game must be. Also compare how "realtime" each of these games really are (hint: time does not always pass at the same pace in each of the forementioned).

To give an example why your design in any of these may differ greatly: Half a second of lag isn't great in a strategy or "build a town" game, but it's acceptable. In a "typical" MMO, you'll have complaints on your user forums or people leaving, and in a shooter game, you will receive massive shit storms and death threats. In a round-based game (which includes pretty much every board/card game), half a second isn't even noticeable.

Compare...

So, I know the games are different. But which conflicts do you see from networking? We can't take slow protocol for a fast-paced game, but we can easily take fast protocol for a slow game. And in case if such protocol already exist, even slow games could use it with no costs for development from this side.

To give an example why your design in any of these may differ greatly: Half a second of lag isn't great in a strategy or "build a town" game, but it's acceptable. In a "typical" MMO, you'll have complaints on your user forums or people leaving, and in a shooter game, you will receive massive shit storms and death threats. In a round-based game (which includes pretty much every board/card game), half a second isn't even noticeable.

I don't see any conflicts here. As I said above, round-based game or any other "slow" game could take "fast" protocol.

"Slow" protocols are exactly "acceptable" for some games, just because they are easier for development.

Faster systems aren't "the same, but faster". They usually have limits on what can be serialised and how much, to keep message sizes down. They may place requirements on your game to store several copies of state, to be able to rewind and replay from previous positions, or to be able to extrapolate from them. They may expect you to be sending a constant stream of redundant updates so that if some are dropped, it doesn't matter. None of that makes sense for a slow turn-based game.

how to handle interpolation or extrapolation

I still don't see any difference in terms of protocol. It could support interpolation or extrapolation, so each game will decide if it's required for them or not and which exact setting they should use for timings and so on.

They usually have limits on what can be serialised and how much, to keep message sizes down.

But we have very complex fast games which have to send lot of data and they are working pretty good – so, it's possible. Of course, such protocol should not be used to, say, sending a media files, but we're talking not about some sort of The Ultimate Protocol, we're talking about pretty narrow use cases – multiplayer game client-server sync, basically.

We can't take slow protocol for a fast-paced game, but we can easily take fast protocol for a slow game.

You do realize that a "slow" protocol is exactly as fast as a "fast" protocol? (Well, that's not true as it stands, but read on!)

A "fast" protocol is primarily not fast because it is any faster. This is, by the way, not limited to user protocols, it is a common misconception about TCP and UDP as well. TCP is exactly as fast as UDP. Except when reordering or packet loss happens.

A "fast" protocol is fast because in presence of packet loss it simply moves on and ignores the lost packet rather than stalling. That, and of course a "fast" protocol is paying a lot more attention to squeeze out the last bit only sending the absolute minimum necessary, leaving anything redundant out -- because only so and so much will fit into a packet.

That's OK for e.g. a shooter where there are not many interesting things other than "this single opponent moves to xyz" and "shoots at you", or "subtract 1 from life points" happening, but they happen in rapid succession, and woe if you don't get them in time.

But in e.g. a "typical" MMORPG you may as well have to transmit information like "This guy at XYZ is wearing a holiday gift hat, and the premium Soul Reaper armor with the Burning Sword of Z'kaaah. Right now he changed clothes and did the 'obscene gesture' emote. The other 45 guys on the screen are wearing...".

Not all of this information has the same importance (for example "orc hits you with axe" is certainly higher priority than "guy 20 meters away changes hats"), and usually there is some rather hefty prioritization going on. While surely able to "afford some more", still a MMO has to pay attention to bandwidth. Just do the math and see what happens when you send out two kilobytes per second to a thousand users all day long. Over a month, that's 5 terabytes (not counting network headers, traffic in the other direction, or other stuff).

A "fast" protocol is fast because in presence of packet loss

Sure, but what does it change? If it's fit for fast complex games, it will fit for slow games anyway.

And, in addition, "fast" games still need to check states and so on "to be sure" - so, they still have to use some kind of "slow" protocol sometimes. And all this could be a part of common protocol, which has stuff for very fast messaging, for "reliable" messaging and how both are related to each other.

Again: I still don't see any conflicts why we can't take a "fast" protocol (I mean, the one which used for a fast complex game) and use it for slow/simple game.

Sure, but what does it change? If it's fit for fast complex games, it will fit for slow games anyway.

Not necessarily, the design between using a "reliable, ordered" and "unreliable" service is an entirely different one.

And, in addition, "fast" games still need to check states and so on "to be sure" - so, they still have to use some kind of "slow" protocol sometimes. And all this could be a part of common protocol, which has stuff for very fast messaging, for "reliable" messaging and how both are related to each other.

Raknet has that. But of course, the ordered, reliable channels are "slow".

Not necessarily, the design between using a "reliable, ordered" and "unreliable" service is an entirely different one.

Yeah, but we're talking about common protocol, not specific implementation. So, each specific game could decide if it's needed to use one or another part of the protocol or not.

Raknet has that

Raknet is specific implementation, not sure they have their protocol specs (please correct me if I'm wrong). Also, AFAIK, Raknet is not yet supported anymore.

Yeah, but we're talking about common protocol, not specific implementation. So, each specific game could decide if it's needed to use one or another part of the protocol or not.

Once you start doing that, you don't have much of a high level protocol yet. If you strip back all the different high level options and just keep the common parts of the protocol, you end up with UDP and TCP, basically... :lol:

To go into details - some games may replicate object movement as:

* a series of position/orientation snapshots, combined with interpolation/extrapolation.

* a spline with start time / arrival time.

* a command of the movement destination, with the assumption that every client will deterministacally move the character to that destination in the same way.

* a mixture of the above.

Some games may do this as server-authoritative, others may be client-authoritative but broadcast by a server, others may be client authoritative but cryptographically checked by peers in a p2p network...

Often when designing online multiplayer gameplay, the realities of what you can and cannot synchronize across the internet (within your client min-spec connection, such as common DSL bandwidth figures, and within your server budget) often end up impacting gameplay decisions. You may want to implement "gameplay mechanic A", but your tech people tell you that it will use up 50% of our bandwidth budget, or increase server hosting costs by two-fold, etc... so you end up going with "gameplay mechanic B" instead.

Designing game rules isn't just about being a great game designer and knowing what players want to play, but also dealing with all the real world constraints, such as technological limitations.

...however, yes, you could write a networking library that implements dozens of different options. Games could then pick the algorithms they want, and mix-and-match different library features to fit their game. Writing that kind of library is a lot of work though! :)

Ok, I've give up until I'll learn all that stuff more closely to find specific arguments. But I'm still sure it's possible to design a more-less high-level common protocol for a multiplayer games...

Anyway, thanks everyone for discussion and patience :D