Q53: 如何设计场景管理？

核心结论

场景管理不是“加载一张地图”，而是“管理一个场景从创建、承载实体、同步、切换到回收的完整生命周期”。

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

• 场景和实例的边界
• 场景内实体如何组织
• 场景切换和跨场景迁移怎么做
• 场景资源和逻辑状态何时回收

如果这些边界不清晰，场景系统会和副本、AOI、同步、资源管理全缠在一起。

一、先区分几个概念

1. 场景模板

描述静态内容，例如：

• 地图资源
• 出生点
• 刷怪点
• 导航数据

2. 场景实例

描述运行时状态，例如：

• 当前玩家和怪物
• 机关状态
• 临时事件

3. 空间划分或分区

这是承载和扩展层问题，不完全等于场景本身。

把这三层分开，后续扩展会清楚很多。

二、场景管理通常要负责什么

至少包括：

• 创建和销毁场景实例
• 管理场景内实体生命周期
• 维护场景级规则和状态
• 协调场景切换和迁移

对于副本和战场，这些职责会更重。

三、场景切换是高风险链路

玩家从一个场景进入另一个场景时，通常不是单纯改个坐标。

还需要处理：

• 旧场景退出
• 新场景准入
• 实体迁移或重建
• AOI 重置
• 客户端状态同步

如果链路没有明确阶段，切场景时就很容易出现黑屏、重复实体或状态丢失。

四、场景实例的生命周期要明确

常见可以分成：

1. 创建
2. 激活
3. 运行
4. 空闲
5. 回收

不同类型场景的策略不同：

• 主城通常长驻
• 副本实例通常按需创建和回收

五、实体组织方式决定管理成本

场景内通常会有：

• 玩家
• 怪物
• 掉落
• 机关
• 临时效果对象

场景管理层要回答：

• 谁负责创建它们
• 谁负责销毁它们
• 谁维护可见性和同步边界

如果全部由各子系统各自管理，场景一致性很快会失控。

六、场景系统和资源系统也要解耦

服务端“场景管理”更多关心逻辑状态，而客户端“场景加载”更关心资源展示。

两者相关，但不能混为一体。

服务端重点是：

• 状态和实体
• 场景规则
• 同步边界

客户端重点是：

• 地图资源
• 模型与特效
• 渲染加载

七、工程上更稳妥的设计

常见做法是：

• 用场景模板定义静态数据
• 用场景实例维护运行时状态
• 场景切换走明确状态机
• 空场景按策略回收

这样主城、副本、战场等不同类型都能统一落在一个框架里。

八、常见误区

1. 场景管理就是地图加载

不对。服务端更关心的是场景实例和实体生命周期。

2. 场景切换就是传送

不对。它涉及会话、实体、同步和客户端状态重建。

3. 场景没玩家就立刻销毁最好

未必。还要看重连、回收成本和是否存在延迟进入需求。

参考资料

• 各类 MMO / ARPG 场景实例和切图管理实践资料