Q49: 如何设计副本系统？

核心结论

副本系统本质上不是“复制一张地图”，而是“为一组玩家临时创建一个受控场景会话”。

真正需要先设计清楚的是：

• 副本实例如何创建和销毁
• 谁能进入、何时进入
• 实例状态如何推进
• 失败、退出、掉线、重连如何处理

如果只把副本理解成场景隔离，后面在进度保存、奖励结算和实例回收上会出很多问题。

一、副本系统真正负责什么

通常包括：

• 创建实例
• 绑定参与玩家或队伍
• 推进副本阶段
• 管理怪物、机关、Boss、结算
• 回收实例资源

所以副本更像“临时场景会话系统”。

二、先区分几种副本类型

常见可以按几个维度区分：

• 单人、副本、团队
• 固定队伍或匹配进入
• 日常、周常、一次性、活动限时

不同类型的核心差异不在地图，而在：

• 准入规则
• 生命周期
• 结算方式

三、副本实例的生命周期要明确

一个常见生命周期通常包括：

1. 创建
2. 准备
3. 进行中
4. 完成或失败
5. 结算
6. 回收

关键是每一步都要有清晰条件，而不是只靠“地图里没人了就删”。

四、进入规则和锁定规则很重要

副本系统通常要回答：

• 谁能进
• 还能不能中途加入
• 是否有次数限制
• 是否需要队长确认
• 是否消耗门票或体力

这些规则一旦不统一，客户端和服务端很容易出现状态错位。

五、掉线、退出和重连不能后补

这是副本系统最常见的真实问题之一。

必须提前定义：

• 掉线后是否保留位置
• 重连是否允许回到原实例
• 主动退出是否还能重进
• 全队离开后实例保留多久

这些直接决定体验和资源回收策略。

六、进度保存要按副本类型分层

不是所有副本都应该保存完整进度。

例如：

• 单次战斗副本可能只需要会话内状态
• 长周期团队副本可能要保存 Boss 击杀进度
• Roguelike 或爬塔副本可能要保存阶段节点

所以“进度保存”不是统一模板，而是玩法决策。

七、奖励结算一定要和实例状态分开

副本完成不等于奖励已经安全发放。

更稳妥的做法通常是：

• 副本状态先进入完成态
• 结算系统再按规则发奖
• 发奖链路具备幂等

否则断线、重试、重复确认时很容易双发或漏发。

八、工程上更稳妥的设计

常见做法是：

• 副本模板定义静态配置
• 副本实例对象维护运行时状态
• 玩家和队伍与实例显式绑定
• 结算和发奖单独成链路
• 空实例定时回收

这样生命周期和资源管理会更清楚。

九、常见误区

1. 副本就是复制一张场景

不够。副本更关键的是会话、进度和结算。

2. 副本结束直接发奖励就行

不对。奖励发放要考虑幂等、掉线和重试。

3. 实例没人就立刻销毁最省资源

这样会直接破坏重连和短暂断线恢复体验。

参考资料

• 各类 MMO / ARPG 副本会话、进度保存与结算实践资料