# 多人游戏设计（Multiplayer Game Design）

多人游戏设计是现代游戏开发中最复杂的领域之一，涉及网络工程、心理学、社会学和系统设计的交叉。本文档涵盖从底层网络同步到上层社交系统的完整知识体系。

---

## 1. 网络同步基础

### 1.1 状态同步 vs 帧同步

| 特性 | 状态同步（State Synchronization） | 帧同步（Lockstep / Deterministic Sync） |
|------|----------------------------------|----------------------------------------|
| **核心原理** | 服务器定期广播各对象状态 | 各客户端只同步输入，本地确定性计算 |
| **带宽需求** | 高（需同步位置、血量等全状态） | 低（仅同步玩家输入） |
| **作弊难度** | 较低（服务器可校验） | 较高（客户端计算，易被篡改） |
| **回滚实现** | 相对简单 | 需全状态快照，复杂 |
| **浮点一致性** | 不要求 | 严格要求 |
| **典型游戏** | 《守望先锋》《CS2》《Valorant》 | 《王者荣耀》《星际争霸》《拳皇15》 |

#### 状态同步的优化技巧

```cpp
// 增量状态同步示例：只发送变化的数据位
struct EntityDelta {
uint32_t changedFields; // 位掩码标记哪些字段变化
Vector3 position; // 仅当第0位为1时有效
Quaternion rotation; // 仅当第1位为1时有效
int16_t health; // 仅当第2位为1时有效
};

// 客户端插值代码示例（Unity C#）
void InterpolatePosition() {
float t = (Time.time - lastStateTime) / sendInterval;
transform.position = Vector3.Lerp(prevPosition, targetPosition, t);
}
```

#### 帧同步的关键实现

```cpp
// 确定性浮点运算（避免不同CPU/编译器结果不一致）
class FixedPoint {
int64_t raw; // 定点数存储，例如 1 = 1000
public:
static const int64_t SCALE = 1000;
FixedPoint operator+(const FixedPoint& other) const {
return FixedPoint(raw + other.raw);
}
// 所有运算避免浮点，确保跨平台一致
};

// 输入同步帧结构
struct InputFrame {
uint32_t frameNumber;
uint32_t playerId;
uint32_t inputMask; // 位掩码：上/下/左/右/攻击/技能
uint16_t aimAngle; // 定点数角度
};
```

**案例分析**：
- **《王者荣耀》**：采用帧同步 + 乐观预测。所有战斗逻辑在客户端运行，服务器只转发和校验输入。为处理断线，每N帧生成一个关键帧校验hash。
- **《Valorant》**：状态同步 + 128 tick 服务器。服务器每7.8ms广播一次世界状态，客户端做插值和预测。

### 1.2 延迟补偿（Lag Compensation）

延迟补偿是 FPS 竞技游戏的核心技术，用于解决"我看到打中了但服务器说没打中"的问题。

```cpp
// 服务器端延迟补偿代码逻辑
void ServerFireWeapon(Player shooter, Ray ray) {
// 获取射击者的 RTT/2（单向延迟）
float latency = shooter.GetLatency();

// 将服务器状态回滚到 latency 前的时刻
GameState historicalState = stateHistory.Rewind(latency);

// 在回滚后的状态下做射线检测
HitResult hit = historicalState.Raycast(ray);

if (hit.IsValid()) {
ApplyDamage(hit.target, weaponDamage);
}

// 无需恢复状态，因为服务器继续推进
}
```

**关键参数**：

| 参数 | 说明 | 典型值 |
|------|------|--------|
| 补偿上限（Max Unlag） | 最大回滚时间 | 200ms |
| 历史缓冲区大小 | 存储多少秒的状态 | 1-2秒 |
| 验证窗口 | 合法延迟范围 | 0-400ms |

**实际案例**：
- **《CS2》**：Sub-tick 系统 + 延迟补偿。服务器记录每一帧的玩家位置，射击时根据玩家 ping 回滚到对应时间。补偿上限约200ms。
- **《守望先锋》**：服务器保存1秒的位置历史，对所有需要精准判定的技能（如黑百合狙击、源氏反弹）启用延迟补偿。

### 1.3 预测与回滚（Prediction & Rollback）

```
玩家按下"向右移动" → 客户端立即预测移动 → 服务器确认/纠正 → 若不一致则回滚并重新模拟
```

**客户端预测流程**：

```cpp
// 客户端预测 + 服务器调和
class ClientPrediction {
queue pendingInputs; // 已发送但未确认的操作

void OnLocalInput(PlayerInput input) {
pendingInputs.push(input);
// 立即应用到本地状态
localPlayer.ApplyInput(input);
SendToServer(input);
}

void OnServerState(GameState state) {
// 服务器返回的状态比本地"旧"，因为网络延迟
if (state.timestamp < localPlayer.timestamp) {
// 回滚到服务器状态
localPlayer = state.playerState;

// 重放所有未确认的输入
for (auto& input : pendingInputs) {
if (input.timestamp > state.timestamp) {
localPlayer.ApplyInput(input);
}
}
}
}
};
```

**案例分析**：
- **《Apex Legends》**：客户端预测角色移动，服务器每50ms发送一次纠正。移动预测准确率>99%，玩家几乎感觉不到纠正。
- **《街霸6》**：基于 GGPO 的回滚网络代码。若预测错误，回滚1-3帧并重新模拟格斗逻辑。rollback 帧数控制在视觉可接受范围内（通常<3帧）。

### 1.4 权威服务器 vs 客户端预测

| 模式 | 信任模型 | 延迟感知 | 反作弊能力 | 适用场景 |
|------|---------|---------|-----------|---------|
| **纯权威服务器** | 仅信任服务器 | 高（所有操作需往返） | 最强 | 回合制、策略游戏 |
| **客户端预测+调和** | 信任客户端即时反馈 | 低 | 强 | FPS、动作游戏 |
| **客户端权威** | 信任客户端 | 最低 | 弱 | 合作PVE、休闲游戏 |
| **混合模式** | 移动预测+伤害权威 | 中等 | 中等 | 大逃杀、MOBA |

**决策检查清单**：
- [ ] 游戏类型是否为高频操作？（是 → 需要客户端预测）
- [ ] 是否允许轻微的状态不一致？（是 → 预测+调和）
- [ ] 安全性要求是否极高？（是 → 伤害计算必须服务器权威）
- [ ] 目标玩家群体的平均网络质量如何？（差 → 需要更强的预测和补偿）

---

## 2. 匹配系统

### 2.1 ELO/Glicko 评分系统

**ELO 系统基础公式**：

```python
def calculate_elo_change(player_rating, opponent_rating, score, k=32):
"""
score: 1=胜, 0.5=平, 0=负
"""
expected = 1 / (1 + 10 ** ((opponent_rating - player_rating) / 400))
new_rating = player_rating + k * (score - expected)
return round(new_rating)

# 示例：1800分玩家 vs 2000分玩家
print(calculate_elo_change(1800, 2000, 1)) # 胜：+24
print(calculate_elo_change(1800, 2000, 0)) # 负：-8
```

**Glicko-2 改进**：

| 特性 | ELO | Glicko-2 |
|------|-----|---------|
| 评分不确定性 | 固定K值 | 动态RD（Rating Deviation） |
| 新玩家校准 | 慢（需很多场） | 快（RD大时波动大） |
| 长期未玩处理 | 无特殊处理 | RD增大，匹配范围扩大 |
| 计算复杂度 | 低 | 中等 |
| 采用游戏 | 早期《英雄联盟》 | 《CS2》《街霸6》 |

```python
# Glicko-2 简化示意：评分不确定性随时间变化
class GlickoPlayer:
def __init__(self, rating=1500, rd=350, volatility=0.06):
self.rating = rating
self.rd = rd # Rating Deviation，越大表示越不确定
self.volatility = volatility

def decay_inactivity(self, periods=1):
"""长期未玩时，RD 增大"""
self.rd = min(350, math.sqrt(self.rd**2 + self.volatility**2 * periods))
```

### 2.2 技能匹配（SBMM - Skill-Based Match Making）

**现代匹配系统的多维评分**：

```python
class PlayerSkillProfile:
"""现代游戏的技能评估不止一个数字"""
def __init__(self):
self.combat_rating = 1500 # 枪法/格斗技巧
self.strategy_rating = 1500 # 战术意识
self.teamwork_rating = 1500 # 配合度
self.communication_rating = 1500 # 交流频率（语音/信号）
self.consistency = 0.8 # 发挥稳定性（方差倒数）
```

**匹配质量 vs 排队时间权衡**：

| 策略 | 排队时间 | 匹配质量 | 玩家满意度风险 |
|------|---------|---------|--------------|
| **严格SBMM** | 长（高分段尤甚） | 高 | 玩家抱怨排不到人 |
| **放宽范围** | 短 | 中等 | 新手被虐，高手无聊 |
| **动态范围** | 自适应 | 自适应 | 需要精细调参 |
| **分区匹配** | 中等 | 高 | 服务器成本增加 |

**动态匹配范围算法**：

```python
def find_match(player, queue_time_seconds):
base_range = 100 # 初始分差范围

# 随着时间推移扩大搜索范围
expanded_range = base_range + (queue_time_seconds ** 1.5)

# 但设置上限避免差距过大
max_range = 500
search_range = min(expanded_range, max_range)

# 优先找范围内的，若找不到则逐步放宽
candidates = get_players_within_range(player.rating, search_range)

# 额外因子：连胜/连败玩家的隐藏分调整
adjusted_rating = player.rating + (player.win_streak * 25)

return best_match(candidates, adjusted_rating)
```

### 2.3 区域匹配

```yaml
# 区域匹配配置示例
regions:
asia-east:
datacenters: [tokyo, seoul, taiwan]
max_acceptable_ping: 80ms
fallback_regions: [asia-southeast]

europe:
datacenters: [frankfurt, london, paris]
max_acceptable_ping: 60ms
fallback_regions: [us-east]

# 匹配优先级：先同区域，若排队过久则扩展到邻近区域
```

**实际案例**：
- **《英雄联盟》**：早期采用纯区域服务器（国服、美服、欧服）。后推出"跨区匹配"，在排队时间过长时合并附近大区。
- **《Apex Legends》**：玩家可选择数据中心，也可自动选择最低延迟。匹配系统在数据中心内执行，避免跨区域高ping。

---

## 3. 反作弊系统

### 3.1 常见作弊类型

| 作弊类型 | 实现方式 | 检测难度 | 典型影响 |
|---------|---------|---------|---------|
| **透视（Wallhack）** | 修改渲染、内存读取敌方位置 | 中等 | 提前知道敌人位置 |
| **自瞄（Aimbot）** | 自动将准星锁定目标 | 中等 | 命中率异常高 |
| **加速/瞬移** | 修改本地时间戳、位置包 | 低（服务器可检测） | 移动速度异常 |
| **无后座力** | 移除武器后坐力计算 | 中等 | 弹道过于集中 |
| **雷达外挂** | 读取内存中的敌人坐标 | 高（纯客户端） | 小地图显示全图敌人 |
| **脚本宏** | 自动化按键输入 | 高（模拟正常输入） | 瞬间完成复杂操作 |
| **DDOS/网络层** | 攻击对手网络 | 低（网络层检测） | 使对手掉线/高ping |

### 3.2 客户端校验

```cpp
// 客户端完整性校验示例
class ClientIntegrity {
// 1. 内存签名扫描：检测已知作弊软件特征码
bool ScanMemorySignatures() {
for (auto& signature : knownCheatSignatures) {
if (FindPatternInMemory(signature)) return false; // 发现作弊
}
return true;
}

// 2. 代码完整性校验：确保游戏代码未被修改
bool VerifyCodeIntegrity() {
auto currentHash = HashGameModules();
return currentHash == expectedHash;
}

// 3. 驱动级/内核级反作弊（如 Easy Anti-Cheat, Vanguard）
// 在 Ring 0 层运行，监控系统调用和内存访问
};
```

**主流反作弊方案对比**：

| 方案 | 运行层级 | 侵入性 | 检测能力 | 采用游戏 |
|------|---------|--------|---------|---------|
| **BattlEye** | 内核驱动 | 高 | 强 | 《彩虹六号》《ARK》《PUBG》 |
| **Vanguard（Riot）** | 内核驱动 | 高 | 很强 | 《Valorant》《英雄联盟》 |
| **Easy Anti-Cheat** | 内核+用户层 | 中高 | 强 | 《Apex》《堡垒之夜》《原神》 |
| **VAC（Valve）** | 用户层 | 低 | 中等 | 《CS2》《DOTA2》 |
| **内核级自定义** | 内核驱动 | 高 | 最强 | 《王者荣耀》《和平精英》 |

### 3.3 服务器权威校验

```python
# 服务器端移动校验
class MovementValidator:
def validate_move(self, player, from_pos, to_pos, time_delta):
max_speed = player.get_max_speed()
distance = from_pos.distance(to_pos)
actual_speed = distance / time_delta

# 允许 10% 的网络误差缓冲
if actual_speed > max_speed * 1.1:
return False, "Speed hack detected"

# 检查是否穿墙（射线检测）
if not self.is_path_clear(from_pos, to_pos):
return False, "Wall clip detected"

# 检查垂直速度（防止飞天）
if to_pos.y - from_pos.y > self.max_jump_height:
return False, "Fly hack detected"

return True, "OK"

# 射击校验
class CombatValidator:
def validate_shot(self, shooter, target, hit_pos):
# 1. 检查射线路径是否被遮挡
if not self.has_line_of_sight(shooter.eye_pos, hit_pos):
return False

# 2. 检查武器射程
if shooter.distance_to(target) > shooter.weapon.max_range:
return False

# 3. 检查射击间隔（射速限制）
if time.now - shooter.last_shot_time < shooter.weapon.fire_interval:
return False

return True
```

### 3.4 行为分析

```python
# 统计异常检测系统
class BehaviorAnalyzer:
def analyze_aim_patterns(self, player, session_data):
"""检测非人类瞄准特征"""
suspicious_score = 0

# 1. 瞄准平滑度：人类有微抖动，自瞄过于平滑
smoothness = calculate_aim_smoothness(session_data.aim_samples)
if smoothness > 0.99: # 近乎完美的平滑
suspicious_score += 40

# 2. 反应时间：人类平均200-300ms，自瞄接近0
reaction_times = session_data.reaction_times
if np.mean(reaction_times) < 50: # 50ms以下非人类
suspicious_score += 30

# 3. 爆头率异常
headshot_rate = session_data.headshots / session_data.total_kills
if headshot_rate > 0.8 and session_data.total_kills > 20:
suspicious_score += 20

# 4. 预瞄（Pre-aim）精度：提前对准即将出现的敌人
preaim_accuracy = calculate_preaim_accuracy(session_data)
if preaim_accuracy > 0.9:
suspicious_score += 10

return suspicious_score

def detect_repeated_offenders(self, player):
"""累加多次轻微异常，触发人工审核"""
# 不单次封禁，而是累积信誉分
player.trust_score -= self.calculate_penalty(player.recent_reports)
if player.trust_score < 30:
return "shadow_ban" # 影子匹配（只匹配到其他可疑玩家）
```

**反作弊实施检查清单**：
- [ ] 所有伤害计算和位置更新必须经过服务器校验
- [ ] 客户端内存加密，防止简单修改
- [ ] 通信协议加密（防止抓包修改）
- [ ] 行为数据上报（瞄准轨迹、移动模式）
- [ ] 影子封禁系统（延迟封禁，避免打草惊蛇）
- [ ] 人工审核后台（查看疑似作弊者的第一视角录像）
- [ ] 硬件ID封禁（防止简单换号）
- [ ] 定期更新反作弊模块（对抗新版本外挂）

---

## 4. 社交系统设计

### 4.1 好友系统

```protobuf
// 好友系统协议设计（Protocol Buffers示例）
message FriendRequest {
uint64 requester_id = 1;
uint64 target_id = 2;
string message = 3; // 附言
uint64 timestamp = 4;
Status status = 5; // PENDING / ACCEPTED / DECLINED
}

message FriendInfo {
uint64 user_id = 1;
string nickname = 2;
Status online_status = 3; // OFFLINE / ONLINE / IN_GAME / AFK
uint32 current_game_mode = 4;
uint64 last_online = 5;
int32 friendship_level = 6; // 亲密度等级
}

// 好友状态广播（Presence系统）
message PresenceUpdate {
uint64 user_id = 1;
Status new_status = 2;
string status_message = 3; // "竞技模式 - 比分 12:10"
}
```

**好友系统设计要点**：

| 功能 | 设计考量 | 实现方案 |
|------|---------|---------|
| **在线状态** | 大规模广播压力 | 只广播给好友，采用XMPP/WebSocket长连接 |
| **跨平台好友** | PC/主机/手机互通 | 统一账号体系，平台仅作为设备属性 |
| **最近组队** | 临时社交关系 | 自动保存最近10场队友，可一键添加 |
| **备注名** | 仅客户端存储 | 不占用服务器存储，换设备需重新设置 |
| **好友上限** | 社交压力与存储成本 | 通常300-500人，VIP可扩展 |

### 4.2 公会/战队系统

```yaml
# 公会系统数据结构
guild:
id: "uuid"
name: "Thunder Wolves"
tag: "[TW]" # 游戏内显示前缀
emblem: "custom_image" # 徽章
max_members: 50

roles:
- name: "Leader"
permissions: [all]
limit: 1
- name: "Officer"
permissions: [invite, kick, promote, start_clan_war]
limit: 5
- name: "Member"
permissions: [chat, participate]
limit: 44

activities:
- type: "clan_war" # 公会战
schedule: "每周六 20:00"
- type: "raid" # 团队副本
difficulty: "hard"

progression:
level: 12
xp: 4500
perks: ["+5% xp boost", "weekly supply drop"]
```

**案例分析**：
- **《命运2》**：公会系统与游戏进度深度绑定。公会成员完成活动可为公会贡献XP，解锁全公会共享的奖励。每周重置时根据公会等级发放奖励。
- **《英雄联盟》**：俱乐部系统（已简化）。早期有独立的俱乐部排位赛，后因参与度低改为以战队标签和开黑组队为主。

### 4.3 语音聊天

| 方案 | 延迟 | 音质 | 开发成本 | 适用场景 |
|------|------|------|---------|---------|
| **自研（WebRTC）** | 低 | 可调 | 高 | 大型竞技游戏 |
| **Vivox（Unity）** | 低 | 高 | 低 | 中小团队 |
| **Discord集成** | 低 | 高 | 极低 | 休闲游戏 |
| **Steam语音** | 中 | 中 | 低 | Steam平台游戏 |
| **GameChat（Xbox）** | 低 | 高 | 低 | 主机/跨平台 |

```cpp
// 语音聊天频道管理示例
enum VoiceChannel {
TEAM, // 队伍频道（4-5人）
PROXIMITY, // 近场频道（距离衰减）
SQUAD, // 小队频道（大逃杀）
GUILD, // 公会频道
CUSTOM // 自定义房间
};

// 空间音频（近场语音）
void UpdateProximityVoice(Player listener, Player speaker) {
float distance = listener.DistanceTo(speaker);
float volume = 1.0f - (distance / MAX_VOICE_RANGE);
volume = std::max(0.0f, volume);

// 障碍物遮挡
if (IsObstructed(listener, speaker)) {
volume *= 0.3f; // muffled
}

SetVoiceVolume(speaker.channel, volume);
}
```

### 4.4 举报系统

```python
# 举报处理系统
class ReportSystem:
REPORT_THRESHOLD = 5 # 单场被举报次数触发审核

def submit_report(self, reporter, suspect, reason, evidence):
report = {
'suspect_id': suspect.id,
'reporter_id': reporter.id,
'reason': reason, # CHEATING / TOXICITY / AFK / INTING
'match_id': current_match.id,
'timestamp': now(),
'evidence': evidence, # 截图、录像片段、聊天记录
'reporter_credibility': reporter.report_accuracy # 历史举报准确率
}

# 存入待审核队列
self.report_queue.add(report)

# 实时处理：单场被举报过多，立即触发自动检测
if self.get_match_reports(suspect, current_match) >= self.REPORT_THRESHOLD:
self.trigger_automated_review(suspect, current_match)

def automated_review(self, suspect, match):
"""自动化初步筛查"""
# 1. 检查聊天日志中的关键词（辱骂）
toxicity_score = analyze_chat_logs(match.chat_logs, suspect)

# 2. 检查行为数据（挂机：长时间无输入）
afk_score = detect_afk(match.player_actions, suspect)

# 3. 若自动检测确认，执行临时措施
if toxicity_score > 0.9:
return Action.MUTE_24H
if afk_score > 0.95:
return Action.LEAVER_PENALTY

# 否则进入人工审核队列
return Action.MANUAL_REVIEW
```

**信誉系统案例**：
- **《Dota 2》**：行为分系统（1-10000分）。被举报、放弃比赛、辱骂会扣分。低分玩家匹配到一起，形成"低优先级队列"。
- **《Valorant》**：XP和竞技模式分开惩罚。被证实作弊永久封禁，言语辱骂可禁言1-7天。

---

## 5. 多人游戏模式

### 5.1 PvP（竞技对战）

| 子类型 | 玩家数量 | 典型规则 | 代表游戏 |
|--------|---------|---------|---------|
| **死斗（Deathmatch）** | 4-16人 | 自由混战，击杀得分 | 《使命召唤》 |
| **团队死斗（TDM）** | 8-16人 | 分队对抗，先到击杀数获胜 | 《光环》《战地》 |
| **占领/控制（Control）** | 6-12人 | 争夺地图控制点 | 《守望先锋》《Valorant》 |
| **爆破/搜索摧毁（Bomb）** | 10人 | 一队安炸弹，一队阻止，无复活 | 《CS2》《彩虹六号》 |
| **MOBA** | 10人 | 推塔、兵线、英雄技能 | 《英雄联盟》《DOTA2》 |
| **格斗（Fighting）** | 2人 | 1v1，多回合制 | 《街霸》《铁拳》 |

**竞技模式设计检查清单**：
- [ ] 胜负条件清晰、无歧义
- [ ] 回合时间控制在合理范围（3-5分钟/回合）
- [ ] 经济/成长系统防止滚雪球（劣势方有翻盘机会）
- [ ] 暂停/投降机制（防止被拖时间）
- [ ] 排位积分算法透明
- [ ] 赛季重置与奖励机制

### 5.2 PvE（合作对战）

```yaml
# 合作副本难度设计
coop_mission:
name: "zombie_outbreak"
player_count: 4
difficulty_scaling:
# 动态难度：根据队伍表现实时调整
enemy_health: base * (1 + 0.2 * player_count)
enemy_damage: base * (1 + 0.15 * player_count)
spawn_rate: base + (2 * player_count) # 每分钟刷新数

roles:
tank: {health_multiplier: 2.0, threat_generation: high}
healer: {revive_cooldown: 60s, healing_output: scaled_by_difficulty}
dps: {damage_output: primary_objective}
support: {buff_duration: 30s, crowd_control: stun/slow}

fail_conditions:
- all_players_down
- time_limit_exceeded: 1800s
- objective_destroyed
```

**案例分析**：
- **《求生之路2》**：AI Director 系统。根据队伍压力水平（血量、弹药、倒地次数）动态调整僵尸生成强度，确保每局体验不同但难度均衡。
- **《命运2》**：副本（Raid）设计需要6人紧密配合，机制复杂到必须语音沟通。成为游戏最高难度内容和社交核心。

### 5.3 大逃杀（Battle Royale）

**核心循环**：

```
跳伞 → 搜刮装备 → 缩圈推进 → 交战/避战 → 最终决战
```

**关键技术参数**：

| 参数 | 典型值 | 设计原因 |
|------|--------|---------|
| 单局人数 | 60-150人 | 足够密度形成随机遭遇 |
| 地图大小 | 4x4km - 8x8km | 支持百人降落与载具移动 |
| 单局时长 | 20-30分钟 | 手机端可缩短至10-15分钟 |
| 缩圈间隔 | 3-5分钟 | 制造移动压力 |
| 初始安全区 | 全地图的50% | 第一阶段不逼迫移动 |

**网络优化挑战**：

```cpp
// 大逃杀的距离优先同步（Interest Management）
class ReplicationGraph {
void UpdateReplication(Player viewer) {
for (Entity entity : allEntities) {
float distance = viewer.DistanceTo(entity);
float priority = CalculatePriority(entity, distance);

// 距离越近，同步频率越高
if (distance < 10m) syncInterval = 0.016s; // 60Hz
else if (distance < 50m) syncInterval = 0.033s; // 30Hz
else if (distance < 200m) syncInterval = 0.1s; // 10Hz
else if (distance < 500m) syncInterval = 0.5s; // 2Hz
else syncInterval = 2.0s; // 仅位置

// 超出视距的实体不同步细节
if (distance > viewer.cullDistance) {
entity.ReplicateMinimal(); // 只同步存在性
}
}
}
};
```

**实际案例**：
- **《PUBG》**：早期采用虚幻引擎默认网络复制，100人同局性能差。后自研 ReplicationGraph，按距离和优先级分层同步。
- **《Apex Legends》**：60人小地图大逃杀，强调小队（3人）协作。网络同步优化到极致，服务器60 tick，延迟补偿覆盖全武器。

### 5.4 MMO 架构

**分层架构**：

```
客户端 ←→ 网关层（Gateway/Login） ←→ 游戏逻辑层（Zone Server）
↓
数据库层（DB Cache + Persistent DB）
↓
公共服务（聊天、邮件、拍卖行）
```

```python
# MMO 区域服务器（Zone）管理
class ZoneServer:
MAX_PLAYERS_PER_ZONE = 1000

def handle_player_move(self, player, new_position):
# 1. 检查是否跨越区域边界
if self.is_crossing_boundary(player.position, new_position):
target_zone = self.get_zone_for_position(new_position)
self.transfer_player(player, target_zone)
return

# 2. 更新位置，通知同区域可见玩家
player.position = new_position
nearby_players = self.spatial_hash.query(new_position, VISIBLE_RANGE)
self.broadcast_position_update(player, nearby_players)

def transfer_player(self, player, target_zone):
# 跨服迁移：保存状态 → 通知目标服 → 断开旧连接 → 建立新连接
player_data = player.serialize()
target_zone.accept_player(player_data)
self.remove_player(player)
```

**案例分析**：
- **《魔兽世界》**：分 realm（服务器）+ 跨服副本。野外按 realm 分隔，副本可跨服匹配。7.0后引入"分片"（Sharding）技术，自动将拥挤区域拆分到多个物理服务器。
- **《最终幻想14》**：单一世界服务器架构。通过强大的区域服务器动态分配，理论上所有玩家可在同一"世界"中。

---

## 6. 技术架构

### 6.1 专用服务器（Dedicated Server） vs P2P

| 维度 | 专用服务器 | P2P（点对点） |
|------|-----------|-------------|
| **主机成本** | 高（需租用/自建服务器） | 零（玩家承担） |
| **作弊防护** | 强（服务器权威） | 弱（选主机为权威） |
| **延迟分布** | 相对公平（都连服务器） | 主机0延迟，其他玩家高 |
| **NAT穿透** | 不需要 | 复杂（STUN/TURN/中继） |
| **断线影响** | 服务器宕则全局断 | 主机退则全房解散 |
| **适用规模** | 任意（1-1000+人） | 通常<8人 |
| **典型游戏** | 几乎所有竞技网游 | 《怪物猎人》（早期）《艾尔登法环》 |

**混合模式**：

```yaml
# 混合架构：P2P for 合作, Dedicated for 竞技
game_modes:
campaign_coop:
network: listen_server # 一人当主机
max_players: 4
anti_cheat: minimal # 合作模式容忍度较高

ranked_pvp:
network: dedicated_server
server_provider: "AWS Gamelift / Azure PlayFab"
tick_rate: 128
anti_cheat: kernel_level
```

### 6.2 区域服务器部署

```yaml
# 全球服务器部署策略
datacenters:
- region: us-east
location: virginia
provider: AWS
coverage: [NA East, SA North]
target_ping: <50ms

- region: eu-west
location: frankfurt
provider: AWS
coverage: [EU West, EU North]
target_ping: <50ms

- region: asia-east
location: tokyo
provider: Alicloud / AWS
coverage: [Japan, Korea, TW, HK]
target_ping: <60ms

- region: asia-southeast
location: singapore
provider: AWS
coverage: [SEA, Oceania]
target_ping: <80ms

# 玩家匹配到最近的数据中心
matchmaking:
primary: lowest_ping
fallback: second_lowest_if_queue_exceeds_60s
```

**服务器成本估算（以一款中等规模竞技游戏为例）[待验证]**：

| 项目 | 规格 | 月成本（USD） |
|------|------|--------------|
| 竞技对战服务器 | 500台 c5.xlarge | ~$80,000 [待验证] |
| 匹配/大厅服务 | 20台 c5.2xlarge | ~$8,000 [待验证] |
| 数据库（Redis + RDS） | 集群 | ~$15,000 [待验证] |
| CDN（补丁、资源下载） | 全球分发 | ~$20,000 [待验证] |
| 反作弊服务 | 按活跃用户计费 | ~$10,000 [待验证] |
| **总计** | | **~$133,000/月 [待验证]** |

### 6.3 负载均衡

```python
# 游戏服务器负载均衡器
class GameLoadBalancer:
def select_server(self, region, game_mode):
candidates = self.get_available_servers(region, game_mode)

# 多维评分选择最优服务器
best_server = None
best_score = float('inf')

for server in candidates:
score = (
server.cpu_usage * 0.3 + # CPU 使用率
server.memory_usage * 0.2 + # 内存使用率
server.network_latency * 0.3 + # 网络延迟
server.player_count / server.max_players * 0.2 # 饱和度
)

if score < best_score:
best_score = score
best_server = server

return best_server

def auto_scale(self, region, game_mode):
"""根据排队长度自动扩缩容"""
queue_length = self.get_queue_length(region, game_mode)
active_servers = self.get_active_server_count(region, game_mode)

# 若平均排队>30秒，扩容
if queue_length / active_servers > 5:
self.spawn_servers(region, game_mode, count=5)

# 若有空服务器>10分钟，缩容
for server in self.get_idle_servers(region, game_mode, older_than=600):
self.terminate_server(server)
```

### 6.4 断线重连

```cpp
// 断线重连系统架构
class ReconnectSystem {
const int RECONNECT_WINDOW = 120; // 允许重连的时间窗口（秒）

void OnPlayerDisconnect(Player player) {
// 不立即移除玩家，标记为"暂离"
player.state = DISCONNECTED;
player.disconnect_time = Now();

// 启动倒计时
StartTimer(RECONNECT_WINDOW, [this, player]() {
if (player.state == DISCONNECTED) {
this->FinalizeDisconnect(player); // 正式踢出
}
});
}

bool AttemptReconnect(uint64 player_id, string session_token) {
auto player = FindDisconnectedPlayer(player_id);

if (!player || player.state != DISCONNECTED) {
return false; // 无法重连，需重新匹配
}

if (Now() - player.disconnect_time > RECONNECT_WINDOW) {
return false; // 超过重连窗口
}

if (!VerifySessionToken(player, session_token)) {
return false; // 会话验证失败
}

// 恢复游戏状态
player.state = CONNECTED;
SendFullStateSnapshot(player); // 发送当前完整世界状态

return true;
}

void SendFullStateSnapshot(Player player) {
// 序列化当前游戏的所有相关状态
GameStateSnapshot snapshot;
snapshot.game_time = current_game_time;
snapshot.entities = SerializeAllVisibleEntities(player);
snapshot.player_state = GetPlayerState(player);
snapshot.scoreboard = GetCurrentScoreboard();

SendToPlayer(player, snapshot);
}
};
```

**不同模式的重连策略**：

| 游戏模式 | 重连窗口 | 暂离处理 | 实际案例 |
|---------|---------|---------|---------|
| **FPS竞技** | 3-5分钟 | AI代管或冻结 | 《CS2》可重连，《Valorant》同 |
| **MOBA** | 5分钟 | AI控制英雄 | 《英雄联盟》5分钟内可重连 |
| **大逃杀** | 2分钟 | 角色原地静止（危险） | 《PUBG》《Apex》支持重连 |
| **合作PVE** | 整局 | 暂停等待或AI接管 | 《求生之路》投票暂停 |
| **MMO** | 无限制 | 角色留在原地一段时间 | 所有MMO均支持随时重连 |

---

## 总结与最佳实践

### 网络同步决策树

```
游戏类型?
├── 回合制/策略 → 纯权威服务器
├── FPS/TPS竞技 → 状态同步 + 延迟补偿 + 客户端预测
├── 格斗/RTS/MOBA → 帧同步 + 回滚网络代码
├── 大逃杀 → 状态同步 + 兴趣管理 + 动态刷新率
└── MMO → 状态同步 + 区域分片 + 分层复制
```

### 多人游戏开发检查清单

**发布前必须验证**：
- [ ] 高延迟测试（200ms+）：游戏是否仍可玩？
- [ ] 丢包测试（5%丢包）：是否流畅？
- [ ] 弱网测试（频繁断线重连）：是否稳定？
- [ ] 作弊压力测试：常见修改内存/抓包工具是否有效？
- [ ] 峰值并发测试：目标并发人数的2倍压力
- [ ] 跨区域匹配测试：不同区域玩家混合的延迟表现
- [ ] 长时间运行测试：服务器运行7天无内存泄漏
- [ ] 断线重连测试：各游戏模式下的重连成功率>99%

**性能基准**：

| 指标 | 优秀 | 可接受 | 差 |
|------|------|--------|-----|
| 服务器 tick rate | 128 Hz | 64 Hz | <30 Hz |
| 客户端输入延迟 | <20ms | <50ms | >100ms |
| 状态同步带宽/玩家 | <10 KB/s | <30 KB/s | >50 KB/s |
| 匹配等待时间（休闲） | <30s | <60s | >2min |
| 匹配等待时间（排位） | <2min | <5min | >10min |
| 断线重连时间 | <5s | <15s | >30s |

---

## 参考资源

- **书籍**：《Multiplayer Game Programming》by Josh Glazer, Sanjay Madhav
- **论文**："1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond"
- **开源框架**：GGPO（回滚网络代码）、ENet、GameNetworkingSockets（Valve）
- **GDC演讲**："It IS Rocket Science!" by Clayton Kroh（《火箭联盟》网络同步）
- **技术博客**：Riot Games Tech Blog、Overwatch Networked Physics