Skip to main content
Game Physics – Complete Beginner to Advanced Guide
CHAPTER 14 Intermediate

Multiplayer Physics and Synchronization

Updated: May 16, 2026
35 min read

# CHAPTER 14

Multiplayer Physics and Synchronization

1. Introduction

A physics engine calculates gravity, collisions, and bounces flawlessly on a single computer. But what happens when you introduce the Internet? It takes 50 milliseconds for a packet of data to travel from Player A to Player B. In those 50ms, a physics object moving at 100m/s has traveled 5 meters. If you don't account for this delay, a bouncing ball will be in a completely different location on everyone's screen. In this chapter, we will tackle the most complex topic in game development: Multiplayer Physics. We will explore the failure of Deterministic networking, the absolute necessity of Server Authority, and the illusions of Client Prediction and Interpolation.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Explain why running independent physics simulations causes "Desync."
  • Understand the Authoritative Server model for physics calculations.
  • Implement Network Transforms to synchronize Position and Rotation.
  • Understand the visual illusion of Interpolation (smoothing out lag).
  • Understand the concept of Client Prediction for responsive gameplay.

3. The Desync Problem (Determinism)

You might think: *If Player A and Player B both drop a ball from 10 meters at the exact same time, the physics engines will calculate the exact same bounce.* FALSE. Physics engines use floating-point math. Different CPUs calculate decimals slightly differently. A microscopic 0.00001 difference in the bounce angle will compound over 5 seconds. Soon, the ball is on the left side of the room for Player A, and the right side for Player B. This is called Desync.

4. Server Authority

Because computers cannot agree, one computer must be appointed the absolute dictator. This is the Server.
  • Only the Server runs the true physics simulation.
  • The Clients (Players) turn their rigidbodies to isKinematic = true. They do not simulate physics at all!
  • The Server calculates the ball bouncing, and 30 times a second, it sends the exact X, Y, Z coordinates to the Clients. The Clients simply teleport the ball to match the Server.

5. Interpolation (Smoothing the Lag)

If the Server only sends coordinates 30 times a second, but the Client is running at 60 FPS, the ball will appear to teleport (stutter) every other frame.
  • The Fix: We use Interpolation (Lerp). Instead of instantly teleporting the ball to the new Server coordinate, the Client smoothly glides the ball from its old position to the new position over the course of a few frames. It is a visual trick to hide network lag.
csharp
123456789
// Conceptual Client-Side Interpolation
Vector3 targetNetworkPosition;
float lerpSpeed = 15f;

void Update()
{
    // Smoothly glide the visual object toward the server's authoritative position
    transform.position = Vector3.Lerp(transform.position, targetNetworkPosition, lerpSpeed * Time.deltaTime);
}

6. Client Prediction (The Illusion of Control)

If you rely entirely on the Server, when the Player presses 'Jump', they have to wait 100ms for the command to reach the Server, the Server to calculate the jump, and send the new position back. This feels horribly laggy and unplayable.
  • Client Prediction: The moment the Player presses 'Jump', the Client *predicts* what the Server will say and instantly moves the player upward locally.
  • Reconciliation: When the Server's data finally arrives 100ms later, the Client checks if its prediction was correct. If it was, nothing happens. If the Server says "You hit a ceiling," the Client instantly snaps the player back to the correct position (Rubber-banding).

7. Visual Learning: The Multiplayer Pipeline

txt
1234567891011121314
[ CLIENT A ] (Presses 'Push Box')
    |
(100ms Ping) Sends Input
    |
    v
[ SERVER ] (Calculates Physics)
   Box Rigidbody moves forward 2 meters.
   Sends new Coordinates (X=5, Z=10) to ALL Clients.
    |
(100ms Ping) Sends Data
    |
    v
[ CLIENT B ] (Receives Coordinates)
   Lerps (glides) the box visually to X=5, Z=10.

8. Best Practices

  • Network Transform Components: Do not write synchronization code from scratch. Use built-in components (like Unity's NetworkTransform or Mirror's NetworkTransform). These components automatically handle the heavy lifting of packing position/rotation data, compressing it to save bandwidth, and applying interpolation.

9. Common Mistakes

  • Syncing Velocity instead of Position: A beginner will try to save network bandwidth by saying, "I'll just tell the clients the ball's velocity, and let them calculate the movement." This leads to massive desyncs because a micro-stutter on a client's PC will alter the time calculation, causing the ball to fly off-course. Always sync the absolute, authoritative Position!

10. Mini Project: Networked Box Setup

Objective: Configure a physics object for multiplayer. *(Conceptual architecture using standard netcode paradigms)*
  1. 1. The Object: A heavy crate.
  1. 2. The Server: The crate has a standard Rigidbody. The Server applies AddForce when players push it.
  1. 3. The Component: Attach a NetworkTransform to the crate. Check "Sync Position" and "Sync Rotation". Check "Interpolate".
  1. 4. The Client: Ensure the Client's C# script sets crateRigidbody.isKinematic = true on startup. The Client will now peacefully watch the server's flawless physics simulation.

11. Practice Exercises

  1. 1. What is the definition of "Desync" in a multiplayer physics game?
  1. 2. Why must standard physics objects (like bouncing balls) have their Rigidbodies set to isKinematic = true on the Client's machine?

12. MCQs with Answers

Question 1

A multiplayer game requires a ball to bounce around an arena. To ensure the ball is in the exact same place on all 10 players' screens, which architecture MUST be used?

Question 2

When a client receives a new position coordinate from the Server, instantly teleporting the visual object to that coordinate causes visual stuttering. What mathematical C# function is used to smoothly glide the object to the new position?

13. Interview Questions

  • Q: Explain the concept of Client Prediction in competitive multiplayer games (like *Counter-Strike* or *Rocket League*). Why is it required, and how does Reconciliation handle incorrect predictions?
  • Q: Why is floating-point determinism impossible to guarantee across different hardware architectures? How does this force game developers into the Authoritative Server model?
  • Q: Contrast the bandwidth usage of syncing 100 physics objects at 60 updates per second versus syncing them at 10 updates per second with heavy Client-Side Interpolation. What are the visual tradeoffs?

14. FAQs

Q: How do massive games like Battlefield sync 10,000 falling building debris pieces? A: They don't! In AAA games, major physics (tanks, player bodies) are perfectly synced by the Server. Purely cosmetic physics (a wall shattering into 100 bricks) are simulated locally on every Client. If a brick bounces left on your screen and right on my screen, it doesn't matter because the bricks do not affect gameplay!

15. Summary

In Chapter 14, we conquered the hardest architectural challenge in game development. We learned that independent hardware cannot be trusted to calculate identical physics, forcing us to rely on a single Authoritative Server. We explored how the Server dictates positional truth, and how Clients utilize Lerp Interpolation to hide the stuttering of network lag. Finally, we peeked into the advanced illusions of Client Prediction, the secret sauce that makes online games feel instantly responsive.

16. Next Chapter Recommendation

Our physics work beautifully, but the game is using 100% of the CPU. We need to optimize. Proceed to Chapter 15: Physics Optimization Techniques.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·