8.3 World Partition 与关卡流送

8.3 World Partition 与关卡流送

本节摘要：World Partition 把大世界切成空间网格，按玩家位置动态装载卸载，用数据层分区协作、用高层细节层级撑住远景。本节讲清网格、数据层、流送源三个核心机制，比较它与旧关卡流送的取舍，最后把一张单一大地图改造成可运行的分区世界。

一张装不下的地图

单机大地图的两种死法很典型：整个世界作为一个关卡，打开要等几分钟，团队协作时互相锁文件，内存随地图面积线性膨胀直到崩溃；或者切成几百张小关卡靠传送点衔接，内存省了，沉浸感碎了一地。背景是内存与协作都是刚性预算，而"世界"的自然形态是连续的——需要的是一套按需装载的空间调度系统。World Partition 做的就是这件事：把世界按网格切块登记，运行时以玩家为中心动态装块卸块，HLOD（高层细节层级）把远处已卸载的块替换成低细节代理，玩家看到的世界依旧连续，内存里始终只有脚下那一圈。

本节在知识体系中的位置：它是空间维度的"按需分发"，与 8.1 的带宽分配共享母题；它是第九章大世界优化的结构基础——第九章的流送卡顿排查，前提是你懂这套装载机制。

三个机制：网格、数据层、流送源

空间网格是装载的基本盘：世界被划分为可调大小的格子，每格记录自身资产与加载范围，玩家进入某格的流送范围即装载。格大小的权衡是装载粒度与调度开销：格子过小，跨块资产引用与装载调度频繁；过大，单块装载卡顿明显。网格层级支持嵌套（粗格细格两级），核心区用细格精调度、外围用粗格省开销。

数据层解决"同一空间的多份内容"：每个数据层是一个可独立启停的内容分区——白天版与夜晚版的地表装饰、玩法版本A与版本B的关卡布置、编辑期专用的调试物品。数据层与运行时状态联动，进战斗关装饰层、开夜晚亮灯光层，都是一层数据的启停而不是资产搬运。它同时是团队协作的解药：不同工种各占一层（玩法、美术、音频），提交互不踩脚。

流送源回答"谁来决定装载哪里"：默认是玩家位置，也可以是任何注册的源——护送目标车辆、 remotely 观战的镜头、即将抵达的增援队伍。多流送源让系统按"最需要的地方"装载，而不是只盯着玩家。与流送相对的是常驻：出生点、核心地标标记为常驻，永不卸载。

分区世界的装载全景

与旧关卡流送的取舍

老项目普遍用子关卡流送：手工把世界切成子关卡，用流送体积或蓝图控制开关。它与 World Partition 的取舍很直白：子关卡可控性强、概念简单，但切分与调度全靠手工，大项目维护成本指数级；World Partition 自动化调度、原生支持协作与数据层，但调试装载问题多一层抽象。选型建议：新项目直接 World Partition；老项目若运行良好不必为了新而新，确要迁移走引擎提供的转换工具——它会按当前关卡布局自动生成网格划分，人工再修边角。

案例：把一张两公里地图改成分区世界

背景：开放地图项目原是一张整体大关卡：打开五分钟、四人协作锁文件、内存逼近上限。目标：转成分区世界并验证装载平滑。

操作：第一步，在关卡设置里启用 World Partition，引擎按当前内容自动生成网格划分，编辑器里可视检查每格内容量——把异常巨大的格子（通常是被一个巨型资产撑起来的）单独调整。第二步，跨格引用体检：分区后跨格硬引用是卡顿与泄漏的高发区，把跨格引用改成软引用（4.2 的挂单方式），或把强耦合资产放进同一格。第三步，建数据层协作规范：玩法、美术、音频各占一层，每层独立启停验证。第四步，生成 HLOD：按区块生成远景代理，检查远景轮廓没有明显塌陷。第五步，运行验证：角色沿最长直线跑穿地图，观察装载卡顿帧与内存曲线；再把第二流送源挂到载具上，验证多源并行。

结果：编辑器打开时间从五分钟降到秒级，运行穿图无明显卡顿帧，内存峰值降到原来的三分之一。

解读：这笔账的结构与 8.1 同构——把"全量常驻"改造成"按需分发"后，省下的是峰值，付出的是调度复杂度与新的故障面（跨格引用、HLOD 穿帮）。收益最大的一项其实是团队协作：按格与按层提交后，锁文件冲突从日常痛点降为偶发事件，这在大团队里比内存账更值钱。变式一：地下城与地表共存——地下城内容放独立数据层，入口触发时启动该层，空间上重叠的两份世界互不干扰。变式二：昼夜系统——景观层做昼、夜两套，按游戏内时间切换，比动态改所有灯光便宜得多。变式三：老子关卡项目过渡——先把子关卡转成关卡实例核对内容，再启用分区转换工具，分批验证而非一步到位。

常见坑：跨格放"钩子"资产（一个蓝图引用几十个格内的物件）。它被装载时会把引用的跨格资产全部拖住，网格化的内存收益被这一根线扯漏——跨格关系要么软引用化，要么物理上同格。

本节要点回顾

• 网格是装载基本盘，格大小权衡粒度与调度，层级网格适配核心区与外围。
• 数据层是空间上的多份内容，运行时启停，也是团队按工种协作的解药。
• 流送源决定装载位置，多源并行让世界"为需要而装"，常驻块保护核心体验。
• HLOD 撑远景连续性，生成后要人工检查轮廓塌陷。
• 跨格引用是分区世界的头号泄漏源，软引用化或物理同格，二选一。

高频问答

问：玩家高速移动（飞行、载具）时装载追不上怎么办？
三招叠加：给移动载具注册为第二个流送源（它前方自然扩展装载圈）、提前量参数让装载沿移动方向前探、把高速走廊沿途的关键资产标记为低细节常驻。纯靠调大流送范围是下策——内存账单会跟着范围暴涨。

问：卡在流送边界上"悬浮在没加载的地面上"怎么治？
这是可见性与装载判定不同步：视野里块还没加载完。对策是把玩家出生点与快速移动的落点放常驻块，配合"装载完成才放行"的门禁逻辑（传送与出生处做流送状态检查）。治本是让玩家移动速度与装载速度在体验上解耦。

问：多人游戏里每个玩家的装载圈不一样，听谁的？
服务器按所有玩家位置的并集装载（它要模拟所有人），客户端只按本地玩家装载。这意味着服务器的内存账单随人数涨——专用服务器的内存规划要把这一项算进去，第八章说"人数上限反推自服务器预算"，这里就是预算的大头之一。

分区世界的一页迁移核对单

老项目转分区时逐项过：跨格引用清点（软引用化或同格化）、巨型格子拆解（被单体大资产撑爆的格）、常驻块指定（出生点与核心地标）、数据层规划（按工种分工）、HLOD 生成与轮廓检查、装载压力测试（最长直线穿图）。核对单走完，转换就不再靠运气——第九章的迁移实战同样依赖这种清单化思维。