Multiplayer Game Development
Networking architecture and synchronization principles.
1. Architecture Selection
Decision Tree
What type of multiplayer?
│
├── Competitive / Real-time
│ └── Dedicated Server (authoritative)
│
├── Cooperative / Casual
│ └── Host-based (one player is server)
│
├── Turn-based
│ └── Client-server (simple)
│
└── Massive (MMO)
└── Distributed servers
Comparison
| Architecture | Latency | Cost | Security |
|---|
| Dedicated | Region and load dependent | Hosting dependent | Can enforce server authority |
| P2P | Topology dependent | Relay costs may apply | Peers require validation |
| Host-based | Host location dependent | Relay costs may apply | Host remains a trust boundary |
2. Synchronization Principles
State vs Input
| Approach | Sync What | Best For |
|---|
| State Sync | Game state | Simple, few objects |
| Input Sync | Player inputs | Action games |
| Hybrid | Both | Most games |
Lag Compensation
| Technique | Purpose |
|---|
| Prediction | Client predicts server |
| Interpolation | Smooth remote players |
| Reconciliation | Fix mispredictions |
| Lag compensation | Rewind for hit detection |
3. Network Optimization
Bandwidth Reduction
| Technique | Savings |
|---|
| Delta compression | Send only changes |
| Quantization | Reduce precision |
| Priority | Important data first |
| Area of interest | Only nearby entities |
Update Rates
| Type | Rate |
|---|
| Position | 20-60 Hz |
| Health | On change |
| Inventory | On change |
| Chat | On send |
4. Security Principles
Server Authority
Client: "I hit the enemy"
Server: Validate → did projectile actually hit?
→ was player in valid state?
→ was timing possible?
Anti-Cheat
| Cheat | Prevention |
|---|
| Speed hack | Server validates movement |
| Aimbot | Validate legal shots; this alone does not detect automated aiming |
| Item dupe | Server owns inventory |
| Wall hack | Don't send hidden data |
5. Matchmaking
Considerations
| Factor | Impact |
|---|
| Skill | Fair matches |
| Latency | Playable connection |
| Wait time | Player patience |
| Party size | Group play |
6. Anti-Patterns
| ❌ Don't | ✅ Do |
|---|
| Trust the client | Server is authority |
| Send everything | Send only necessary |
| Ignore latency | Design for 100-200ms |
| Sync exact positions | Interpolate/predict |
Remember: Never trust the client. The server is the source of truth.
When to Use
Use when selecting multiplayer authority, synchronizing state, testing latency compensation, or preventing inventory duplication.
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
Verification
Treat tables as design starting points, not guarantees. Prototype the selected mechanic, test accessibility and recovery paths, and measure frame timing, memory and behavior on target hardware before claiming completion. Store submission and licensing requirements must be checked against current official platform documentation.
