Computer physics

Question

How to simulate two client-driven vehicles colliding (intelligently) in a typical client / server setup for network play? I read this prominent blog post on how to make distributed network physics as a whole (without traditional client prediction), but this question is specifically devoted to how to handle conflicts of objects belonging to them.

Example

Suppose client A is 20 ms ahead of the server, client B 300 ms ahead of the server (taking into account both latency and maximum jitter). This means that when both cars collide, both clients will see the other as 320 ms behind - in the opposite direction from the speed of the other vehicle. Head to head on the Swedish highway means a difference of 16 meters / 17.5 yards!

What not to try

It is almost impossible to extrapolate the positions, since I also have very complex vehicles with joints and bodies around the perimeter, which, in turn, have linear and angular positions, speeds and accelerations, not to mention the states from user input.

Answer 1

What I ended up just skipped the alltogether prediction and just did it:

• The client talks a lot about his own position,
• The server (almost) only says something about the position of the client’s owner when a collision with “high energy” occurred with another dynamic object (ie, not a static environment).
• The client accepts meshoffset=meshpos-physpos when receiving a positional update from the server, and then sets meshpos=physpos+meshoffset every frame and meshoffset gradually reduced.

It looks good in most cases (in a low-latency situation), I don’t even need to cut my quaternions to get smooth transitions.

Skipping a prediction probably gives customers with a high latency a terrible experience, but I don’t have time to dwell on it if I ever intend to send this indie game. From time to time it’s nice to create a half-ass solution that works pretty well, but better.;)

Edit: In the end, I added the “ownership” function that Glen Fiedler (the blogger mentioned in the question) implemented for Mercenaries 2: each client receives ownership of the (dynamic) objects that they encounter for some time. This was necessary because penetration otherwise becomes deep in situations with high latency and high speed. This concession works as well as you might think when you see the GDC video presentation, I definitely recommend it!

Answer 2

I do not know the ideal solution, and I have the feeling that it is not. Even if you could accurately predict the future position of the vehicle, you could not predict how the user will control the controls. Thus, the problem boils down to minimizing the negative effects of client / server delays. With this in mind, I would like to approach this from the perspective of the principle of least surprise (reworded from Wikipedia):

In user interface design, the principle of least surprise (or surprise) states that when two elements of an interface conflict or are ambiguous, the behavior should be the one that will least surprise a person when a conflict occurs.

In your example, each user sees two cars. Their own and the other player. The user expects that their own car will behave exactly the way they control it, so we cannot play with this aspect of modeling. However, the user cannot know exactly how the other user controls his car, and I would use this ambiguity to hide the lag from the user.

Here is the basic idea:

• The server must decide on an impending collision. The collision detection algorithm should not be 100% perfect, it should be close enough to avoid obvious inconsistencies.
• As soon as the server determines that the two vehicles will collide, it sends each of the two users a message stating that a collision is imminent.
• On client A, the position of vehicle B is adjusted (realistically) to ensure that a collision occurs.
• On client B, the position of vehicle A is adjusted (realistic) to ensure that a collision occurs.
• During a collision, the position of each vehicle can be adjusted as necessary so that the end result matches the rest of the game. This piece is exactly what MedicineMan suggested in his answer .

Thus, each user is still in full control of their own car. When a collision occurs, it will not be unexpected. Each user will see the movement of another vehicle towards them, and they will still have a sense of simulation in real time. It's nice that this method responds well to low latency conditions. If both clients have low latency connections to the server, the size of the adjustment will be small. The end result, of course, will worsen as the gap increases, but this is inevitable. If someone plays a fast-paced game for connecting with a delay of a few seconds, they simply will not get the full experience.

Answer 3

Perhaps the best thing you can do is not to show the actual collision in real time, but to lead to the illusion that everything is happening in real time.

Since the client is behind the server (lagging), and the server needs to show the result of the collision, it’s possible that you can do it on the client side — show a flash or explosion or some other pattern to distract the user and buy enough time on the server side, to calculate the result of the collision. When you are done with the forecast, you send it back to the client side for presentation.

Answer 4

Sorry, answer "What not to try", but I have never heard of a solution that does not involve predicting the result on the client side. Consider a simplified example:

Client A is stationary and the vehicle monitoring of Client B is approaching a cliff. The B-car client is able to instantly reduce speed to 0 and does this at the last moment before crossing the cliff.

If client A is trying to show the status of client B in real time, client A has no choice but to predict that client B fell from a cliff. You see this a lot in MMORPGs designed so that the player’s character can stop immediately when operating at full speed. Otherwise, client A can simply show the status of client B, since state updates are arriving, but this is impractical since client A should be able to interact with client B in real time in your scenario (I suppose).

Could you try to simplify the collision models so that extrapolation is possible for real-time prediction? Perhaps your “joints and bodies around the world” have less intense physical activity, such as several cubes or spheres. I'm not too good at how to improve collision detection performance, but I guess this is done by detecting collisions of models that are less complex than visual models.

Answer 5

Regarding "What not to try." You assume that you need to accurately predict, but you will never find the perfect solution in a game with complex physics. Probably the zoom is the best you can do (for example, most commercial physics engines can overlay the shape on the physical scene and return the first point of collision).

For example, I implemented some critical pieces of network physics for Mercenaries 2 under the direction of Glenn (the blog poster you mentioned). It was impossible to push all the necessary physical state through a wire even for one solid body. Havok’s physics gradually generates contact points in each frame, so the current “contact manifest” is a necessary part of the physical state in order to maintain a deterministic simulation. This is also too much data. Instead, we sent the required transformation and speeds, and also used forces and moments to gently push in place. Errors are inevitable, so you need a good error correction scheme.

Answer 6

Few thoughts.

• Other peers are better off with latency and high speeds.

So, if this is your own engine, switch to a peer. Then you extrapolate another peer-to-peer vehicle based on the input of their buttons to move forward where it is now. You have encountered such a collision that you have collided with another vehicle, as if it were a world. That is, you take a hit.

This means that when you encounter another, you bounce, on a peer-to-peer network, they bounce off of you, so it looks roughly right. The lower the latency, the better it works.

2. If you want to go client / server, then it will be worse than p2p

What to do o) Extrapolate clients forward, as in p2p, to perform collision detection. o) Send collision results back to customers and extrapolate forward

Please note: this will NEVER be as good as p2p. Basically high speed and latency = error, so removing latency is the best strategy. P2P does this.

Answer 7

In addition to predicting on the client side where another user might be, and sending information about the collision and how you processed it on the server, most MMOs to cope with the backlog are that the server works “in the past” , how it was. Mostly they accumulate the last entries, but only respond to what happened .1sec in the past. This allows you to “look into the future” when you need to (i.e. when a collision occurs in your time frame, you can look at the buffered input to see what happens and decide if the collision is real).

Of course, this adds an additional level of complexity to your program, since you need to consider what data to send to your customers and how they should respond to it. For example, you can send the entire “future” buffer to clients and let them see which potential collisions really happen and which don't.

Answer 8

Ross has a good moment. You can simplify the model that you use for collision detection by abstracting it into some simpler volume (i.e., Rough square outline of the vehicle). Then you can make predictions based on a simple volume and detailed calculations on exact volumes, while the user is distracted by the “explosion”. This may not be ideal, but it will allow you to speed up collision detection.