Lag compensation with networked 2D games

Question

I want to make a 2D game that is basically a physics driven sandbox / activity game. There is something I really do not understand though. From research, it seems like updates from the server should only be about every 100ms. I can see how this works for a player since they can just concurrently simulate physics and do lag compensation through interpolation.

What I do not understand is how this works for updates from other players. If clients only get notified of player positions every 100ms, I do not see how that works because a lot can happen in 100ms. The player could have changed direction twice or so in that time. I was wondering if anyone would have some insight on this issue.

Basically how does this work for shooting and stuff like that?

Thanks

Answer 1

Summary for those that don't like long answers...

It can be done but it's impossible to do perfect multiplayer physics if there is any latency. Why latency impacts physics is explained, and then tips for reducing the impact of latency on your physics simulation are offered.

---

Creating a multiplayer physics game can be fraught with peril. It is impossible to create a "perfect" online multiplayer physics experience. There are things you can do to make it better, but there is no way to make perfect physics assuming any latency.

The problem is, physics has to be fast and responsive to be realistic, but at the same time has to be calculated based on the combined actions of ALL factors -- meaning the combined actions of all players. And if there is latency, this can't be done in real time.

It is up to you as a developer to decide if you can keep the different factors under control, and to understand that the player's experience will degrade if the latency becomes too high. If you can live with that (and your players can), then go for it. See towards the end of this post for some notes about how you can keep things running smoother.

An example to show how things can get messed up

Imagine a game where two players (clients) are connected to a server. It takes 100 milliseconds (1/10th second) for a message to go across the internet from client to server. When a player does something, a message is sent to the server saying what they did. The server then broadcasts the message out to the other players so they all know what the acting player did.

Now create a scenario where two players have a crate on the ground which is a physics object. Player A hits it on one side, sending it moving in some direction. However at the same time, player B hits it on another side, sending it another direction.

Let's look at different ways to handle this and what the results would be...

What if physics is calculated just on the server?

Suppose we have the physics calculated only on the server. Player A sends "I hit crate this way" message to server, 1/10th second later server gets message. Player B sends their "I hit crate this other way" message. The server calculates physics change from the combination of the two actions, and sends message back to both players saying, "OK it moves like this." Perfect physics is performed, based on the actions of both players combined.

But the problem is, it will be 2/10th of a second before either player sees the crate react. The messages from both players take 1/10th of a second to reach the server, then another 1/10th of a second for the servers calculation results to be sent for both players.

Bottom line, laggy gameplay.

What if physics is just calculated on the client?

Suppose we have physics calculated on just the client. Let's look at it from Player A's point of view. Player A hits crate and it immediately starts going their direction. A message is also sent to the server saying what Player A did.

At the same time though, B has done their hit and seen the crate going in their direction and sent a message to the server about what they did.

2/10th of a second later, a message arrives from the server to the clients. A is told what B did, and B is told what A did. The problem is, both clients say, "Well player X may have done that hit at this spot, but there is no longer a crate at that location, so their hit did nothing."

Bottom line is, two games out of sync and players not having a shared experience. What's the point of multiplayer if they both see different things?

What if physics is calculated on both client and server?

In this case, physics is calculated on the client so players see an immediate no-lag reaction, but it's also calculated on the server so it is "correct" for all players.

Both players hit the crate their respective directions and each sees the crate move based on their hit only. But then 2/10th of a second later, the server comes back and says, "Well actually, you are both wrong. The crate went this way." Suddenly both players see the crate drastically change directions and glitch to a new location.

Bottom line is, a glitchy game.

Conclusion

Basically there is no way to make a perfect physics game with multiple players when any kind of latency exists. You can make a pretty good game, but you always will have the risk of excessive latency creating a bad experience for some players. However there are things you can do to keep your game experience a good one.

Things you can do to make a multiplayer game run well

Use simple collision volumes. Don't bother modeling every detail of a shape with physics when a simple cube shape will do. A spikey ball doesn't have to be modeled as a spikey ball for physics. Instead just model it as a sphere.

Make small inconsequential objects client-only items. An example might be bits of broken glass from a broken window. You can let each client simulate it on their own, and it won't really matter if they are different.

Only make objects physics objects if they need to be physics objects to keep the number of active physics objects low.

Run your game in slow motion when doing multiplayer physics. Think "bullet time" maybe. Slow motion games compensate for latency and allow multiple players to interact with physics together.

Allow players to setup a situation of some kind together, and then on some cue, the physics is simulated for both players and both watch the result of their combined actions. Players may not interfere with the sequence until it is completed.

Separate players phsyics so they can't interfere with each other. This would be great for a game like bowling or pool, where only one player at a time has control, or each player has their own "sandbox" (like a bowling lane).

If you can't beat 'em, join 'em and make physics lag be part of your game. Imagine a story about being in a glitchy universe with broken physics laws or something :)

Appendix: How shooting games deal with it

Shooting games deal with it by not doing overly complex physics. They do use client side effects so players see things quickly, but then the server makes the final call on what has happened.

Imagine a scenario where player A shoots player B. Your typical shooter game will do something like this...

1. A will locally calculate if they hit B, and if it looks like there is a hit, it plays a "hit" effect like a blood puff. This is done client side so that the player immediately sees a reaction to their action. If you don't do this, the game feels laggy.
2. A also sends a message to the server saying, "I shot along this vector"
3. When the server gets the message, it looks at where IT thinks the players are, and decides if A's shot vector hits B.
4. If the server decides A hit B, it decides B is hit, and sends a message to BOTH clients saying what happened.
5. If the server decides A did NOT hit B, B is fine, and A "misses". It may look to A like they hit ("I saw the blood puff!") but it's the servers call that they missed.

So how could A miss B when it looked like they hit them? Because B may have moved, but A hasn't seen it yet because the server hasn't sent a, "B moved to here" message yet to the client.

Valve has a good writeup on their site about this. See http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Answer 2

I've written a series of articles about the topic here: http://www.gabrielgambetta.com/fpm1.html

The first three articles deal with an introduction to the topic, client side prediction, server reconciliation, and entity interpolation (this is the part that answers your specific question). The 4th article (coming soon) will deal with "shooting stuff" :)

Tim Holt's answer is pretty much it. My articles have a couple of diagrams that may help you understand what's going on, but Tim and I are basically saying the same thing.

Answer 3

It's not unreasonable to do full prediction on your own character for responsiveness and to have other characters lag behind by 100ms for consistency. If this looks bad then consider having your own character lag slightly to keep them in sync. Either way you're still going to need correction mechanisms to smooth out incorrect predictions in the event of lag spikes, and that system will deal with situations like the one you describe. It doesn't matter whether the latency is 100ms or 1ms - your client is always 'late' in some sense and therefore always has to act like it is dealing with old data and apply cosmetic effects such as interpolation to make it look reasonable.

Answer 4

In the end its all about making do with the available network resources. Ideally we would live in a world with zero latency and everything can be perfectly synchronized. Realistically, you update the clients every 100, 200, 300 ms and in the client there needs to be logic in place to make what has happened look smooth. The "smoothness" is very important, in the end the game just needs to feel smooth even if at the back end there is some chaotic synchronization happening between client and server.

A good post and better answer can be found:

How to write a network game?

Answer 5

The problem isn't really the latency. It can be compensated and predicted quite well to hide any problems caused it. Packet loss isn't a problem either - the networking system should be written to be robust and tolerable for packet loss. However, the problem is the lag spikes and unpredictable latency. Packets arriving out of sync, some of them being dropped only because of latency swings, inability to predict and interpolate because of latency swings etc.