25 · 多人、联机与社交系统
25 · 多人、联机与社交系统
先读这一句:多人的成本通常是单人的 2–4 倍(网络、服务器、反作弊、客服、跨平台)。 独立游戏做多人的失败率远高于成功案例。没有强理由,不要做。
1. 先决策:该不该做多人
| 问 | 否 → |
|---|---|
| 核心循环是否因为多人而变得本质不同?(而非"加了个人一起玩") | 不做 |
| 团队是否有网络编程能力或预算外包? | 不做 |
| 能否接受发售后持续承担服务器/客服成本? | 不做(可做 P2P/本地) |
社交是否是可传播性的来源(见 principles/05 §6)? |
权重下降 |
| 单人模式是否独立完整? | 必须做,否则死 |
关键判断:"单人玩也完整,多人玩更好" 是健康结构。 "单人玩没意思,必须组队" 是高风险结构——没队友时游戏不存在,而匹配需要玩家基数。
低风险替代方案(强烈推荐给小团队):
- 本地合作(同屏/分屏)
- 异步社交(幽灵数据、留言、种子分享、排行榜)
- Friendslop 式临时联机(用平台联机服务,不自建服务器)
2. 四种联机形态与成本
| 形态 | 网络要求 | 成本 | 系统设计影响 | 例子 |
|---|---|---|---|---|
| 本地合作 | 无 | 低 | 共享屏幕的注意力分配;UI 分区 | 双人成行(3A) / 小团队的分屏 |
| 异步社交 | 极低 | 极低 | 幽灵、留言、排行榜、种子分享 | 大部分独立游戏的正确选择 |
| 在线合作 | 高 | 中高 | 状态同步、断线重连、进度归属 | Lethal Company、Deep Rock |
| 在线竞技 | 最高 | 最高 | 权威服务器、匹配、反作弊、延迟补偿 | 独立游戏慎选 |
成本明细(在线合作参考):
- 网络层实现与调试:总工期的 20–40%
- 服务器与运维:持续现金流
- 反作弊与安全:持续投入
- 客服与举报处理:持续人力
- 测试成本翻倍(需要多客户端并发测试)
3. 网络模型对系统设计的硬约束
| 约束 | 设计要求 |
|---|---|
| 确定性 | 同样的输入序列 → 同样的结果(否则不同步)。禁用无种子的随机、禁用浮点不确定性 |
| 状态同步量 | 同步的数据量必须可控。不要同步"每个敌人的每个属性",同步"影响结果的输入" |
| 权威归属 | 谁说了算?客户端权威(易作弊)还是服务器权威(成本高) |
| 延迟容忍 | 玩家操作到反馈的时间。>150ms 会让操作感崩溃 |
| 断线与重连 | 必须能恢复到一致状态(否则队友丢档) |
| 存档归属 | 谁是 host?host 走了怎么办?进度存在谁那里? |
设计上的应对:
- 本地预测 + 服务器校正(手感)
- 输入延迟补偿(判定回溯)
- 把"必须同步"的东西做少:回合制、异步、事件驱动比帧同步容易得多
- 降低实时性要求是独立游戏最有效的降本手段
4. 社交循环设计
多人游戏的循环不是"玩法循环",是社交循环。
[想和朋友一起] → [约定时间] → [一局] → [产生共同记忆/梗] → [想再玩一次] → ...
| 环节 | 设计手段 |
|---|---|
| 想一起玩 | 低门槛加入(一键邀请)、单局短、可中途加入 |
| 产生共同记忆 | 意外事件、搞笑失败、可炫耀时刻(见 principles/05 §6 可传播性) |
| 想再玩 | 每局有变化;有明确的下一个目标 |
三种社交动机(SDT 归属需求):
| 动机 | 设计 |
|---|---|
| 合作 | 角色互补(不同能力)、必须沟通的信息 |
| 竞争 | 排行榜、非对称对抗、可比较的指标 |
| 陪伴 | 低压力共存(一起种地、一起看风景) |
社交安全(必须做):
- 举报与拉黑
- 静音/屏蔽
- 语音默认关闭(或仅好友)
- 无强制语音
- 明确的行为准则
5. 玩家流失管理(联机最大的体验杀手)
| 问题 | 对策 |
|---|---|
| 中途退出 | 允许 AI 接管 / 缩短单局 / 不惩罚退出(惩罚会导致更差体验) |
| 人数不足 | 支持 1 人也能玩 / 动态难度 |
| 队友水平差异大 | 非对称角色(新手做简单事)/ 动态难度 |
| AFK | 超时自动托管,不锁死进度 |
| 匹配不到人 | 这是最致命的:小基数游戏不要设计必须匹配的模式 |
| 存档不同步 | 以 host 为准 + 备份 + 明确提示 |
铁律:任何联机系统都必须能"单人完成全部内容"。 否则游戏在玩家基数不足时死亡。
6. 反作弊与信任设计
| 手段 | 说明 | 成本 |
|---|---|---|
| 设计让作弊无意义 | 合作 PVE 作弊不损害他人 → 不必重投入 | 零(首选) |
| 服务器权威 | 关键判定在服务端 | 高 |
| 客户端校验 | 轻量校验,挡住低级作弊 | 低 |
| 行为分析 | 统计异常检测 | 中 |
| 不信任客户端输入 | 校验移动速度、伤害范围等 | 中 |
独立游戏策略:
- PVE 合作:几乎不必反作弊(作弊只影响自己)
- PVP 竞技:必须服务器权威,否则不要做 PVP
- 排行榜:分层(好友榜/全球榜分开),并对异常值做标记而非直接封禁
7. 联机系统的可测试性
必须自动化,否则无法回归(见 production/24)。
| 能力 | 用途 |
|---|---|
| 多客户端并发测试 | 一键启动 N 个客户端跑同一局 |
| 延迟/丢包模拟 | 注入 50/150/300ms 延迟与 5% 丢包 |
| 确定性回放 | 记录输入序列,回放验证结果一致 |
| 断线注入 | 随机断开一个客户端,验证重连 |
| 状态比对 | 每 N 帧比对所有客户端的状态哈希 |
验收标准:
- 300ms 延迟下仍可玩(回合制/异步可放宽)
- 5% 丢包下不崩
- 任意时刻断线可重连并恢复一致状态
- 输入回放 100% 复现结果(确定性验证)
- 单人可完成全部内容
8. 反模式
| 症状 | 修法 |
|---|---|
| 单人玩没意思,必须组队 | 必须让单人完整;或改异步社交 |
| 强制匹配的 PVP | 小基数游戏会死于匹配不到人 |
| 客户端权威 + PVP | 必被作弊摧毁,改服务器权威或不做 PVP |
| 无种子的随机 + 联机 | 必然不同步 |
| 同步每个实体的每个属性 | 改为同步输入/关键事件 |
| 惩罚退出 | 导致更差的体验;改 AI 接管 |
| 语音默认开启 | 社交安全事故高发;默认关 |
| 无举报/拉黑 | 必须做 |
| 进度只存在 host | 明确提示 + 备份 + 允许迁移 |
| 无延迟模拟测试 | 上线才发现 300ms 下不可玩 |
| 无确定性回放测试 | 不同步 bug 无法复现 |
| 无头/无并发测试工具 | 手工开两个客户端测不完 |
9. 交付物
- 多人决策结论(做/不做 + 形态选择 + 理由)
- 网络模型规格(权威归属、同步内容、延迟目标、重连策略)
- 社交循环图(社交动机 + 共同记忆的产生点)
- 社交安全清单(举报/拉黑/静音/准则)
- 联机测试方案(并发客户端 + 延迟注入 + 回放 + 断线)
10. 参考
playbooks/18-genre-playbooks.md§18.7 社交合作principles/05-genre-and-high-concept.md§6 可传播性production/24-testing-and-qa.md(确定性、回放、自动化)- 案例:Lethal Company、Deep Rock Galactic、Among Us(产品力 + 等待传播窗口)