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, Zcoordinates 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
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
8. Best Practices
-
Network Transform Components: Do not write synchronization code from scratch. Use built-in components (like Unity's
NetworkTransformor Mirror'sNetworkTransform). 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. The Object: A heavy crate.
-
2.
The Server: The crate has a standard Rigidbody. The Server applies
AddForcewhen players push it.
-
3.
The Component: Attach a
NetworkTransformto the crate. Check "Sync Position" and "Sync Rotation". Check "Interpolate".
-
4.
The Client: Ensure the Client's C# script sets
crateRigidbody.isKinematic = trueon startup. The Client will now peacefully watch the server's flawless physics simulation.
11. Practice Exercises
- 1. What is the definition of "Desync" in a multiplayer physics game?
-
2.
Why must standard physics objects (like bouncing balls) have their Rigidbodies set to
isKinematic = trueon 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 utilizeLerp 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.