How do fast paced multiplayer games like shooters and MMORPGs maintain fairly fluid combat when everyone can have differing network connection speeds?
In: Technology
First, minimize the processing that they have to do on their end. You move your mouse, this moves the character’s arm. You press the button to fire. The gun fires a bullet. The bullet travels to another player. The game calculates whether it’s a hit and applies the damage to the other character.
The server doesn’t care about any of the graphics side, so leave that to your computer to handle. All the server needs to know is the location of the players (three numbers) and the direction and speed of the projectile (two numbers). It then performs a rather simple mathematical calculation and sends the results back.
Most of the resource intensive stuff are graphics which they just let you handle on your own? You can’t handle those graphics? Sucks to be you.
Second, on the server side, they have enough servers that are fast enough to handle all of the incoming information that they do actually receive, process it fast enough, and send it back to the player.
Third, they don’t actually care whether you get a response in a timely manner. The type of network connection they use is basically “fire and forget”. Your computer sends the information to the servers, but it doesn’t wait for a response. This is why network lag is perceived by players suddenly jumping around or freezing in place, because your client continues to process your actions, rendering the graphical part, but isn’t receiving any info about anyone else to render theirs. For minor lag issues, you never notice and the game just continues to proceed as if nothing is wrong.
Ping is the time it takes to get places, where as bandwidth is how much you can bring at a time. advertised internet speeds are in bandwidth, because ping depends on how far away whatever you’re connecting to is so is different for every single thing you try and do.
The amount of data you have to transmit for a game is super low. It’s like “I’m going here I fired a gun”. because of that Your bandwidth basically doesn’t matter much at all for gaming, it’s your ping.
Most “local” (within the same country) pings are between 20 and 250 ms. This is between 1/50th and 1/4 of a second. Often unnoticeably fast
Also games use predictive algorithms to show you what is probably going to happen – a running player can’t stop suddenly, so it shows them still moving. It will correct it within a fraction of a second if it’s wrong when it actually gets the new data. If you’ve ever seen someone standing in place or running into a wall then suddenly there in a new spot, this is an extreme version of that – the game is predicting they’re doing the same thing because it’s not getting that players data, then when it finally does get data it goes oh I was wrong!
Different games do different levels of prediction on the server versus on your computer that gets very complicated but that’s the basics
I assume by different connection speeds you mean different latency.
There are multiple approaches to this. In general, the server has definitive say on what happens. Clients tell server what they want to do. Of course there is some delay between your click and server receiving the request. These delays can be different for different players.
Easiest think to do is to target some specific delay, let’s say it’s ok for your game to have 100ms delay (that’s equivalent to 6 frames at 60fps). If my packet takes 60ms to get to the server, it will sit there doing nothing for 40ms. If someone else’s packet takes 80ms to get there, it does nothing only 20ms. This ensures that server had collected inputs of all players from the same point in past and can simulate next step. This ensures no-one has advantage by being closer to server (unless your packets take too long to fit in this window), and small changes in network latency doesn’t cause problems, because you artificially make bit bigger, but constant. This approach is fine for many games, but you wouldn’t want to use this for first person shooter.
If you need quick responses, you can simulate game on server and clients synchronized without any delay. Let’s say receives some input that you stopped walking. It knows that it took the packet let’s say 100ms to get to it, so it looks where you were 100ms ago, and simulate 100ms of staying in place from that point. If the delays are short enough, no-one will notice anything. If the delay is bigger, you’ll see players jumping around a bit as the server receives updated inputs. This has the advantage that what you as an player see is exactly what the server sees, without any delay, unless you do something. This isn’t big deal, for example, in FPS, you are running for few seconds (which equals to hundreds of frames), then few frames have to be recalculated because you stopped. Maybe you are changing the rotation more often than that, but that doesn’t affect the gameplay much if there is some delay or stuttering.
When I write it like this, it looks simple, but IRL, games probably use combination of these approaches and more, plus some game specific tweaks. For example in FPS, it doesn’t matter if sound of you yelling “smoke” is delayed by fraction of second, but if players disagree if someone got shot or not, it’s bigger deal. RPGs might be easier to deal with as there is bigger tolerance for small constant delay and many actions do take some time (for example, when you fire some projectile, it can take longer to hit the target than for packet to travel between client and server).
One important thing is that these times we are talking about are really tiny, almost insignificant. Techniques mentioned above are there just to make the experience even better.
Latest Answers