How do online multiplayer games work so well despite so many differences in the systems behind each user (processing power, internet speed, display refresh rates)?
In: Technology
They work so well because there is, usually, a server behind them that streamlines the differences in players’ specs.
Display refresh rate doesn’t play any significant role usually. Frame rate on the other hand, sometimes can. Some games can, for instance, say a skill animation is 10 frames with the effect being applied at the last skill. For a player, whose device runs at 30fps, the whole thing takes 0.3s. one with 120fps – 0.085ish seconds. This can play a huge advantage in more competitive games.
It’s usually the server’s job to gather all the information, process it and send it back to all the players in a meaningful way.
Internet speed isn’t a massive bottleneck as the data the players’ device is sending is usually rather small, network ping is. That’s the time it takes for a packet of data, as in, ‘I’m moving here, casting this, using that item, and so on, to reach the server, or for the server data, again ‘player X cast this, enemy has Y health, etc, to reach the players.
Internet issues are by far the bigger hurdle in online games. You’ve definitely seen/experienced rubber-banding, lag, etc. Those are due to either the server not receiving the information at all or receiving it too late.
Tldr: there is a server on the other side that keeps track of everything and makes sure it’s a streamlined experience for all.
They avoid dealing with those issues at all tbh. What you send them isn’t what’s on your screen you send your inputs. Then your inputs get sent and the game reacts to them on your screen and the server. Lag is actually a result of this process being interrupted.
To restate for clarity everyone just puts inputs in and the server sends that info to everyone playing whose computer then interprets them.
You only send a very small amount of data to the server, which are usually just numbers, for things like your position, where you moved, if you pressed fire, etc. It’s a tiny amount of data.
The server knows how long it takes for you to send information from your computer to the server – this is your “ping” or “lag.”
So, the server can then take this information and perform a little math on it so if I have a lower ping than you, my action doesn’t happen before your action. This is called normalization. A lot of normalization happens on your side too (the client side). For example, the game engine should make sure that any action you make (moving, firing a weapon, etc) takes priority over very taxing operations, like rendering the graphics. That way if you have a slower video card or your computer chokes on a very intensive scene, your actions make it to the server first.
Then, the server sends that information, again, as a small amount of numerical information, back to the program running on everyone’s computer.
All game engines do this a bit differently and arguably, the Source game engine behind games such as GS:GO do it the best.
In the early days of online gaming, whoever had the fastest connection won. Playing Quake on dialup against someone on a T1 was hopeless.
[Not ELI5 but for aspiring game developers this article is long but fantastic on the topic of netcode and dealing with lag.](https://arstechnica.com/gaming/2019/10/explaining-how-fighting-games-use-delay-based-and-rollback-netcode/)
ELi5 for the article: There are 2* main ways to handle lag in online games. Delay or sometimes called Input Lag and Rollback.
Delay is exactly what it sounds like inputs will be delayed into a buffer for a tiny unnoticeable amount of time. If both players in the case of a two person game, or all players in case of more get their inputs in in time everything goes smoothly and it is rendered cleanly. The problem with Delay is you don’t render if you don’t get everyone ones input, which means if one person sees a delay longer than the buffer allows for the game will pause and wait. Again the article goes into greater detail.
Rollback is pretty neat and sounds like it would never work but it does, again read the article if you have time and inclination. Essentially if a input is dropped in rollback the game just keeps rendering by guessing what the player is probably doing, and if it finds out it guessed wrong it just rolls back the game state. How does it guess? well that is more complicated but some simple rules are, if they player is holding A for these 5 frames, and then frame 6 we get no input, we will just plug in A for that input on that frame, then keep going. If it turns out that the player Switched to B on frame 6 for some reason we “simply” go back in time and rerender what should have happened had we recieved that input. An incredibly large amount of time nothing will change and the rendering gets to keep chugging forward. This is due to a few things about games, one of which is a lot of your inputs don’t matter. In a fighting game if you just mash buttons, 80% of those button presses or more are just eaten up animation time anyway. The thing about rollback is it sounds like you would constantly just freeze and reset the game state but it doesn’t. Remember when talking about lag you are talking about milliseconds of difference, and we can’t really perceive things as fast as the computer can compute and render them. So they are able to do all of this rollback and re-rendering without us ever noticing.
* Anytime someone tells you are there are 2 main ways, that just means these are the 2 ways we will cover right now but there are more out there.
CTRL-F “tick” *no results found*
Multiplayer games are synchronized between the client and the server with what’s called “ticks” and this is the backbone of all multiplayer games. All clients run at the same tick rate, which is the speed at which the server updates, measured in cycles per second.
For example, on launch, Overwatch had a tick rate of 21. 21 updates per second. Blizzard upped the tick rate to 63 to improve performance. CSGO runs at 64, but there are some servers that run at 128 for better responsiveness.
Game developers use several tricks to make the process seem seamless:
1. Most of the stuff you see in the game is never sent to the server. All of the pretty graphics and character models and level design is just ignored. You can load the level map once at the start of the match, and just keep a copy on the server, instead of sending it back and forth, for instance. What’s actually sent back and forth is really just a short list of numbers: the position, speed, and acceleration of each player, along with which way they were looking, as well as the same for any projectiles, abilities, etc. Each one of these is sent with a timestamp, for reasons I’ll come back to. So, if you have 20 people in the server, plus bullets, spells, npcs, etc. you only have to send a couple hundred numbers back and forth, which is less than a kilobyte of data. This gives a reasonable chance of sending everything quickly enough.
2. The server stores a short “history” of what happened over the last fraction of a second. This is where the time stamp comes in. By the time the notification that you shot your gun gets to the server, it has been a little while since it happened. The server takes the timestamp when the shot occurred, and looks up where everybody was at that time, and decides whether your shot hit at the moment you fired it, and then sends its decision to you and the other players. This is why you can sometimes get hit behind cover, you were shot at a few milliseconds ago, and by the time the server realized you got hit and sent that information back to you, your local computer thought you had safely made it to cover, and has to “catch up” and retroactively apply the damage.
3. The server isn’t updating constantly, only in predefined “ticks”, typically say 60 per second. So, every 1/60 of a second, the server checks if anything happened that needs to be told to all of the player’s computers and sends that out as a batch. If the server wants to store the last 0.2 seconds of gameplay to account for lag as I described above, that’s just the last 12 “ticks” that get stored. This means that it doesn’t matter if the computers of the various players are running at different rates, so long as they can connect to the server around 60 times per second, and never wait more than 0.2 seconds the connection will appear seamless.
4. You only notice problems if your latency is longer than the longest time that the server stores, then your local machine guesses what happened based on its last good information, and you abruptly snap to a different position when the server finally does reconnect to your computer and tells you where everybody actually is. This is what causes the symptoms of “lag”.
Latest Answers