multiplayer – skill Lập trình cho agent AI

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 |

---

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

| 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.