Multiplayer tutorial 1: concepts

Connection quality

A number of measurements can be made to determine the quality of a connection over the Internet, and is a good guide of the likely quality of gameplay that will result. These include latency, packet delay variance (PDV), packet loss and bandwidth.

Latency

As a result of routing devices and the laws of physics, every message sent over the Internet will take some time to arrive at the destination. The transmission time is called the latency, or sometimes the ping time. It is commonly somewhere around 20ms to 200ms for any given two players anywhere in the world, although as any seasoned gamer can tell you, it can sometimes be beyond that range. Games typically run at 60 FPS, meaning each frame takes about 16ms. A latency of 100ms means the game advances about six frames before a sent message arrives at the destination. If it then needs a reply, it doubles: the response will arrive another six frames later.

In action games, response times are very important. Good players often can respond to gameplay events within tens of milliseconds, and they become very sensitive to these delays. Consider a bullet moving at 500 pixels per second. In 200ms it covers 100 pixels, which could easily be the difference between a direct hit and missing by a wide berth.

This latency of data transmission over the Internet creates some difficult problems. For the game to be fair, all players need to be seeing the same thing and have the same opportunity to respond to events. In practice every player is acting on a different time delay and the host must make the decisions about what is really happening. While various techniques are used to compensate for the time delays and try to keep the game fair, any seasoned gamer can also tell you that a low latency serves as a gameplay advantage: you will see things happen slightly before other players do.

Packet Delay Variance (PDV)

Another problem with latency is it can vary for each message. If two messages are sent over the Internet, one could take 50ms to arrive, but the second could take 70ms. This is called the packet delay variance, or PDV. In Construct 2, it is measured as the highest latency minus the lowest latency over the last few measurements, so in the given example would be 20ms. A high PDV tends to be worse than high latency. The multiplayer engine anticipates when messages will arrive and attempts to compensate for the delay. A high latency with a low PDV means the predictions about arrival times work well and the compensations are accurate, resulting in stable gameplay. A low latency with a high PDV means messages arrive unpredictably, and the compensations are sometimes inaccurate, resulting in unstable gameplay as the multiplayer engine has to make corrections, and negating the advantage of a low latency.

Packet loss

Messages can also go entirely missing. While routing devices make a "best effort" attempt to pass messages along, they are allowed to simply drop them if they get flooded with too many messages, run out of memory, crash, lose power, and so on. The percentage of messages that go missing is called the packet loss. The multiplayer engine can easily compensate for occasional packets going missing, but if the packet loss is high the gameplay quality will start to degrade.

A common cause of packet loss is high traffic causing routing devices to get sent messages faster than they can receive or process them. If the capacity is exceeded, some messages will be processed and retransmitted, and the others will be dropped in order to preserve some degree of service. If it had to handle every single message, the backlog would keep increasing with retransmission getting slower and slower until it failed completely. In order to avoid causing this, it is wise to try to transmit smaller messages at the lowest acceptable rate - which also makes them more likely to arrive quickly.

Bandwidth

Finally, the bandwidth refers to the total rate at which data can be sent. All Internet connections have a maximum download and upload rate, often measured in megabits per second. Since there are eight bits in a byte, dividing that by 8 gives you the rate in megabytes per second (since most software systems, including Construct 2, measure data in bytes instead of bits). For example, a 40 megabit/sec connection can in theory transfer 5 megabytes per second. However note the upload rate can be different, and is commonly less in consumer Internet connections.

Bandwidth can be the bottleneck for large games. The more peers join a game, the more data the host must upload to keep all the peers up-to-date. Eventually the host will reach the limit of their upload rate and packet loss will occur. This is another reason to send small messages at the lowest acceptable rate, since it minimises the necessary bandwidth.

I notice this does not address the subject of host cheating. Preventing the clients is nice and all, but, for example, say the host hacks their client, they could now send whatever they want to the peers.

Now you could say that anti-cheating measures and checks could be implemented, but then you could apply that same logic to each client as well.

Also, not to spam, but addressing the "Lag Compensation" techniques. I'm sorry but if a player has a bad connection in a shooter game, too bad for them. Newer games in the Call of Duty series have notoriously infuriating lag comp which is responsible for all sorts of nonsense.

In my opinion it's a technique that is often overused and should not be looked as much as interpolation or other ways of synchronizing between peers.

"By default updates are sent 30 times a second"We will be able to modify this, correct? Or send out updates only when needed? It'd be wasteful to constantly spew out that much data for something like a grid/turn based game, where movement may be as low as 1 grid square per 100ms, or not at all when a player is AFK.