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
2. Synchronization Principles
State vs Input
Lag Compensation
3. Network Optimization
Bandwidth Reduction
Update Rates
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
Validate authenticated player/session ownership, sequence numbers, payload size, rate and legal state transitions on the server. Inventory and purchase grants need atomic/idempotent transitions; merely storing inventory on a server does not prevent duplicate grants. Bound rewind history and timestamps, and test loss/reordering/reconnect as well as latency. Never embed server credentials in clients.
5. Matchmaking
Considerations
6. Anti-Patterns
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.