ARPG 地形设计
ARPG 地形设计是动作角色扮演游戏中战斗空间、环境资产与程序化管线的综合设计学。它不仅是”美术背景”，而是直接决定了战斗可读性、遭遇节奏、内容重玩性以及整个生产管线的基础架构。本文以等角视角 ARPG 为主要切入点，综合 Diablo IV、Path of Exile、Last Epoch、Grim Dawn、Lost Ark 等商业案例与 Bevy 技术实现路径进行深度分析。
1. 地形组织模式：五款游戏的技术对比
| 游戏 | 引擎/技术栈 | 地形组织 | 程序化程度 | 独立开发启示 |
|---|---|---|---|---|
| Diablo IV | 自研引擎 + Houdini PDG | 连续开放世界 + 150+ 程序化地下城 | 高（地下城） | Houdini PDG 管线不可复制，但 Culture Kit 概念可借鉴 |
| Path of Exile | 自研引擎 | 实例化区域 + 程序化地下城/异界 | 极高 | 最适合小团队：tile-based 房间图拼接 |
| Last Epoch | Unity | 战役（handcrafted）+ Monolith（程序化 Echo Web） | 中高（终局） | Unity 生态 + Graph-based 回廊网络 |
| Grim Dawn | Iron Lore 引擎（改进版） | 纯 handcrafted 地形 | 无（除怪物放置） | 品质靠手工量堆，不适合小团队 |
| Lost Ark | Unreal Engine 3 | 3D 等角大世界 + 实例化副本 | 低 | 3D 等角路线复杂度高，美术资产要求极高 |
关键洞察：Diablo IV 的分层地形架构
Diablo IV 的开放世界并非完全”开放”，而是分层设计：
- 宏观层（Overworld）：handcrafted 五大地形区，物理光照 + 天气系统，负责世界观/叙事/视觉多样性
- 微观层（Dungeon）：150+ 个基于 tileset 的程序化地下城嵌入 handcrafted overworld，负责战斗重玩性
- 生产管线：Houdini PDG（Procedural Dependency Graphs）批量生成地下城变体，“Monster Factory” 模式
- Culture Kit：同一 tileset + 不同 asset 排列 = 完全不同的环境叙事（如洞穴 tileset → “海怪巢穴” vs “羊头人入侵现场”）
独立开发启示：先做实例化地下城，后扩展为区域大地图。不要一开始尝试连续开放世界——美术资产量超出一个独立团队的承受范围。
2. 程序化生成：算法谱系与 ARPG 适配度
2.1 核心算法对比
| 算法 | 原理 | 输出特征 | ARPG 适配度 | 适合场景 |
|---|---|---|---|---|
| Drunkard’s Walk | 随机游走生成连通路径 | 自然蜿蜒，但可能混乱 | ⭐⭐⭐ | 洞穴/地下城基础骨架 |
| BSP (Binary Space Partitioning) | 递归二分空间→ 放置房间→ 连接 | 结构规整，可预测 | ⭐⭐⭐⭐ | 建筑内部/地牢 |
| Cellular Automata | 迭代平滑随机种子 | 有机洞穴感 | ⭐⭐⭐ | 自然洞穴/矿洞 |
| Wave Function Collapse (WFC) | 约束驱动的 tile 拼装 | 局部兼容、全局多样 | ⭐⭐⭐⭐⭐ | 复杂环境/城镇 |
| Wang Tiles | 边匹配 tile 铺排 | 非周期性纹理/地形 | ⭐⭐⭐⭐ | 地形纹理 + 宏观布局 |
| Graph-based Room Pool | 预置 room + 图连接规则 | 可控、可读、可设计 | ⭐⭐⭐⭐⭐ | ARPG 最佳实践 |
| Perlin/Simplex Noise | 连续噪声采样 | 自然连续地形（无结构） | ⭐⭐ | Biomes 基础/高度场 |
2.2 ARPG 最佳实践：Graph-based Room Pool（PoE 方法）
Path of Exile 使用 tile-based 随机生成，这是 ARPG 程序化地形的最成熟范式
设计阶段:
美术制作 Room Templates（入口、走廊、战斗 arena、Boss 房、死胡同）
↓
设计连接规则（入口→走廊→arena→Boss）
↓
运行时:
图算法选择 room 序列（保证连通性）
↓
实例化 tiles → 附加 theme overlay（尸体/菌斑/血迹）
↓
放置刷怪点、可破坏物、宝箱
为什么优于纯噪声生成：ARPG 地形需要”可读性”——玩家必须能在 1 秒内判断出口方向、敌人位置、AOE 技能覆盖范围。过于混沌的噪声生成破坏这种清晰度
2.3 WFC 的潜力与代价
WFC 可以从少量输入 tile 生成看似 handcrafted 的复杂地图，但：
- 优点：局部约束保证 tile 兼容性，输出质量高
- 缺点：生成时间不可预测（可能回退），大网格性能差，调参困难
- ARPG 适用：适合”拼接已有 room 的过渡区域”，而非替代 room pool
独立开发建议：从 Drunkard’s Walk + 手工 room pool 开始，逐步引入 WFC 作为辅助。
3. 地形渲染技术：从 Tile 到纹理
3.1 Tile-Based Texture Mapping（PoE 技术）
PoE 使用的关键纹理技术
- Wang Tiles 基础：边颜色匹配保证 tile 间无缝拼接
- 多源纹理合成：1024×1024 主纹理由多层照片基底拼接
- 亮度统一：预模糊层消除拼接前的大面积亮度差
- 接缝优先修复：纹理融合前先处理所有 tile 边界接缝
- Theme Overlay：同一地形 tileset 叠加不同视觉主题（尸体、菌斑、血迹）
3.2 Terrain Splatting（3D 地形）
对于有高度地形的 ARPG（如 Lost Ark、Grim Dawn 的 3D 引擎）：
- Splatmap：RGBA 四通道定义四层纹理的混合权重
- Height-based Blending：用每层纹理的局部高度图进行自然过渡
- Triplanar Mapping：陡峭表面（悬崖）避免纹理拉伸
3.3 等角视角的纹理优化
等角固定视角带来的独特约束：
- 地面纹理只需为 ~45° 视角优化，不需要全角度 quality
- 远处纹理可以更低分辨率（固定相机距离）
- 前景 asset 可能需要透明化处理防止遮挡
4. 等角视角的地形设计约束（Camera-Aware Design）
Diablo IV 明确提出 “Camera-Aware Design” 概念——等角固定视角既是约束也是设计工具。
4.1 视角带来的地形优势
- 构图可控：艺术家专门为固定角度布置前景/中景/远景
- 可玩区域清晰：不会被建筑屋顶或地形遮挡玩家角色
- 扁平化导航：玩家不需要操控相机就能看清整个战斗空间
4.2 等角地形的特殊问题与解决方案
| 问题 | 解决方案 | 实现细节 |
|---|---|---|
| 高度错觉 | Y-sorting（按 Y 轴排序渲染） | 高处物体后渲染，产生深度遮挡 |
| AOE 技能变形 | 椭圆投影（elliptical projection） | 补偿圆形范围在等角视角下的透视畸变 |
| 前景遮挡 | 资产透明度 / 剔除靠近玩家的墙面 | 半透明 shader 或设计为不阻挡 playable space |
| 导航网格 | 2D 网格即可满足 | 不需要复杂的 3D navmesh |
| 纹理透视 | mipmap 需考虑视角变形 | 远距离地面纹理仅从特定角度可见 |
4.3 3D 等角 vs 2D Tile-Based 等角
| 维度 | 3D 等角（Lost Ark, Grim Dawn） | 2D Tile-Based（PoE, Diablo II） |
|---|---|---|
| 地形高度 | 真实 3D 高度场，悬崖/楼梯自然 | 通过 tileset 模拟高度错觉 |
| 视觉质量 | 高（PBR 材质、动态光照） | 中（预烘焙 tileset） |
| 美术成本 | 极高（3D 建模 + 贴图） | 中（2D tile 绘制） |
| 程序化生成 | 复杂（3D tileset + 高度约束） | 成熟（2D tile graph） |
| 独立团队推荐 | ❌ 不推荐 | ✅ 强烈推荐 |
与 arpg-camera-perspective 中的决策相承接：混合视角意味着每块地形需要同时满足两种视角的可用性，管线复杂度翻倍。
5. 战斗空间：Arena Design 与 Encounter Pacing
5.1 遭遇战的空间结构（Footholds）
玩家在遭遇战前需要观察战场、选择立足点的时间窗口。三种经典入口模式：
| 模式 | 设计 | 适用场景 |
|---|---|---|
| 玩家伏击敌人 | 敌人 unaware，暴露在入口视野内 | 开放世界野怪点 |
| 敌人伏击玩家 | 空 room → 玩家深入 midfield → 触发刷怪 | 地下城陷阱 room |
| Vista + 单向入口 | 高处观察但无法攻击，跳下后无法返回 | Boss 战 / 大型 set piece |
5.2 Arena 的地形元素
| 元素 | 作用 | ARPG 特殊性 |
|---|---|---|
| Cover（掩体） | 不是 ARPG 核心（不同于射击游戏） | 但地形障碍可分割战场、制造 choke points |
| Choke Points（瓶颈） | 迫使玩家改变 AOE 策略 | ”一夫当关”爽感 vs 被围困风险 |
| Midfield Threshold（触发线） | 控制遭遇战开始时机 | 到达 room 中央才触发刷怪 |
| Bait（诱饵） | 资源/宝箱诱导玩家进入危险区域 | 高风险高回报的空间叙事 |
| Spawn Closets（刷怪柜） | 不可见区域刷怪后敌人”走出来” | 门、裂缝、天花板等入口点 |
5.3 Combat Story（战斗叙事）
遭遇战是”用动作来讲的故事”
- Beginning：敌人是否 aware？玩家是否掌握布局信息？
- Middle：几波怪？是否有脚本事件（天花板塌陷、增援门打开）？
- Ending：如何告知战斗结束？（沉默、出口开启、BGM 切换）
ARPG 特有：刷怪逻辑（spawn pattern）本身就是地形设计的一部分。远程怪放后排、近战怪放前排、精英怪放中场——地形决定了玩家如何移动、集群如何形成
6. 寻路与导航：地形如何驱动 AI
6.1 导航方案选型
| 方案 | 原理 | 性能 | ARPG 适用场景 |
|---|---|---|---|
| Grid A* | 在 tile grid 上运行 A* | O(N log N) 单 agent | 少量 AI（Boss、精英） |
| Navmesh | 在导航网格多边形上寻路 | O(log N) vs grid | 复杂 3D 地形（Lost Ark 类型） |
| Flow Field | 预计算整张图的流向，所有 agent 读取同一个 field | O(grid) + O(1) per agent | ARPG 海量敌人最佳方案 |
| Hierarchical | 远距离粗粒度规划 + 近距离精粒度 | 适合超大世界 | 开放世界 overworld |
6.2 Flow Field 详解（ARPG 核心寻路方案）
Flow Field（又称 Dijkstra Map）是 ARPG 海量敌人导航的最佳实践
1. 从目标点（玩家）出发，用 Dijkstra 计算每个 cell 的代价距离
2. 每个 cell 存储"向哪个邻格移动能最快到达目标"（flow direction）
3. 所有 AI agent 只需读取自己所在 cell 的 flow direction
4. 代价：O(grid_size) 一次计算，每个 agent O(1) 查询
多 Field 叠加：
- 地形代价 field（沼泽慢、路面快）
- 威胁场（远离危险区域）
- 吸引场（向目标/宝箱移动）
- 分离场（防止 AI 重叠）
Bevy 生态：bevy_flowfield_tiles_plugin 提供 Flow Field 实现；bevy_landmass 提供 navmesh + A* + ORCA 碰撞规避。
6.3 地形代价与 Tile 属性
每个 tile 可以携带导航属性：
// 每个 tile 实体的导航相关组件
struct TileTerrainCost { cost: f32 } // 移动代价倍率
struct TileWalkable { blocked: bool } // 是否可行走
struct TileSpawnPoint { group: EnemyGroup } // 刷怪标记
struct TileAreaEffect { effect: AreaEffect } // 地面效果（毒、火、冰）7. 环境叙事：Biome 与地形可读性
7.1 区域识别（Sense of Place）
Diablo IV 的五个区域各自有明确的地形标识：
- Scosglen：风蚀海岸、茅草渔村、漂白的动物尸体
- Dry Steppes：碱湖、盐壳、地热池、Zakarum 修道院
- Fractured Peaks：冰川、城寨、贫民窟帐遮棚
每个 biome 的材料、建筑样式、植被、光照色板都经过统一设计，玩家不需要地图就能感知”我在哪里”。
7.2 地形与叙事层级的配合
| 层级 | 作用 | 示例 | 实现技术 |
|---|---|---|---|
| Macro（区域地形） | 世界观/情感基调 | 绿色沼泽→血色荒原的过渡 | Biome 色板 + 大气散射 |
| Meso（建筑群/地标） | 导航辅助/目标引导 | 远处塔楼提示城镇方向 | Landmark placement + LOD |
| Micro（细节叙事） | 环境故事/沉浸感 | 尸体摆放暗示怪物类型 | Culture Kit + 随机道具放置 |
7.3 Biome 过渡策略
| 策略 | 描述 | 适用 |
|---|---|---|
| 硬边界 | 两个 biome 在明确分界线上切换 | 地下城入口、传送门 |
| 软过渡 | 渐进式 blending（颜色、植被、粒子） | 开放世界 overworld |
| 叙事过渡 | 用故事元素解释变化（烧毁的森林→灰烬荒原） | 强叙事游戏 |
8. 性能策略：大世界的技术基石
8.1 Chunking（分块）
Tilemap 性能的核心策略：
- bevy_ecs_tilemap：自动 chunk，每个 chunk 渲染为一个 mesh
- 性能对比：每 tile 一个 sprite entity → 24K entities = 16 FPS；chunked mesh → 24K tiles = 稳定 60+ FPS
- 推荐 chunk 大小：32×32 tiles 适合大多数 2D 等角场景
8.2 视锥剔除（Frustum Culling）
对于 isometric 场景
- 将地图划分为 sectors
- 只渲染在相机视锥内的 sectors
- 游戏逻辑与渲染完全解耦：即使 sector 不可见，其内 entities 仍需执行逻辑（AI、冷却等）
8.3 Entity 优化策略
| 策略 | 描述 | 收益 |
|---|---|---|
| Sparse tile storage | 只 spawn 非空 tile 的 entity | 减少 60-90% entity 数量 |
| Chunk-entity 模式 | 一个 chunk 一个 entity，tile 数据存为 Vec | 大幅减少 entity 开销 |
| 不可见 tiles despawn | 超出视距的 tiles 反序列化 | 内存可控 |
| 对象池 | 敌人/特效/投射物复用 | 减少 spawn/despawn 开销 |
Bevy 生态：bevy_sparse_tilemap 采用 sparse 模式；bevy_entitiles 内置 frustum culling 和 tilemap mask。
9. Bevy 技术实现路径（2026-07 更新）
9.1 Tilemap Crate 选型矩阵
| Crate | 版本 | 强项 | 弱项 | 推荐场景 |
|---|---|---|---|---|
| bevy_ecs_tilemap | v0.15.0 | 最成熟，等角/六边支持，chunk 渲染 | API 较重 | 生产级 ARPG |
| bevy_ecs_tiled | - | Tiled 编辑器原生集成 | 依赖 bevy_ecs_tilemap | 有 Tiled 工作流的项目 |
| bevy_entitiles | v0.2.2 | 内置算法（mask, culling, physics） | 维护中，未成熟 | 快速原型 |
| bevy_sparse_tilemap | - | 极致性能，最少 entity | 渲染需自己做 | 超大世界/性能敏感 |
9.2 原生 Tilemap RFC（2026-05）
Bevy 社区正在讨论第一方 Tilemap 渲染支持
- 目标：atlas/array texture、chunk-based 渲染、sparse/dense 双模式
- 分离 tilemap 渲染与高层 API
- Tiled/LDTK 作为编辑器（非运行时依赖）
9.3 导航方案
// bevy_landmass: Navmesh + A* + ORCA 碰撞规避
// 适合少量 AI agent 的高质量寻路
// bevy_flowfield_tiles_plugin: Flow Field
// 适合 ARPG 大规模敌人导航9.4 程序化生成接入点
在 Bevy ECS 中，地形生成是一个 Startup/场景切换时的 System：
fn generate_dungeon(
mut commands: Commands,
room_pool: Res<RoomPool>,
rng: Res<GlobalRng>,
) {
// 1. 加载 room pool（预制的 tilemap 片段）
// 2. 用图算法选择 room 序列（BSP/Drunkard/WFC）
// 3. 实例化为 tile entities，附加组件：
// - TileTerrainCost, TileWalkable（导航）
// - TileSpawnPoint（刷怪）
// - TileAreaEffect（地面效果）
// 4. 运行时通过 Changed<TileTexture> 做动态更新
}9.5 编辑器工作流
| 工具 | 用途 | Bevy 集成 |
|---|---|---|
| Tiled | 设计 tileset、autotile 规则、导出 JSON/TSX | bevy_ecs_tiled |
| LDTK | 现代 2D 关卡编辑器，内置等角支持 | bevy_ecs_ldtk |
| Houdini | 专业程序化内容生成（类似 D4 管线） | 无直接集成，可导出 tileset |
10. 地形-系统集成：Terrain-Driven Architecture
10.1 地形作为数据中枢
地形不仅仅是视觉层——它是多系统的数据载体：
┌──→ 碰撞系统（Walkable/Blocked）
TILE DATA ────────┼──→ 导航系统（Cost/Pathfinding）
│ ├──→ 刷怪系统（Spawn Points/Groups）
│ ├──→ 技能系统（Area Effects/AOE modifiers）
│ ├──→ 视觉系统（Texture/Animation/Particles）
│ └──→ 叙事系统（Biome/Theme/Culture Kit）
10.2 刷怪与地形的耦合度
| 耦合模式 | 描述 | 优缺点 |
|---|---|---|
| 地形携带 spawn point | 每个 room template 内置刷怪标记 | 简单直观，但灵活性低 |
| 独立刷怪系统 | 刷怪逻辑读取地形数据决定 spawn 位置 | 灵活，但需额外 AI 逻辑 |
| 混合 | 地形提供候选 spawn zone，刷怪系统按情况选择 | 推荐 |
10.3 地面效果系统
ARPG 常见地面效果（如 PoE 的 Burning/Chilled/Shocked Ground）：
- 作为 tile-level component 管理
- 支持叠加规则（如毒地面 + 火地面 = 爆炸）
- Bevy 实现：
TileAreaEffectcomponent + 定时清理 System
11. 设计决策框架
以下是为 Bevy ARPG 项目的完整决策清单：
必做决策
| # | 决策点 | 选项 | 推荐（独立团队） |
|---|---|---|---|
| 1 | 地形组织模式 | 纯实例化地下城 / 区域大地图+嵌入式地下城 / 开放世界 | 实例化地下城 + 固定 hub |
| 2 | 技术路线 | 2D Tile-Based / 3D 等角 / 混合 | 2D Tile-Based |
| 3 | 生成策略 | 纯手工 / Room Pool + 随机拼接 / 全程序化 | Room Pool + 随机拼接 |
| 4 | Tileset 美术 | 像素风 / 手绘 / Stylized 3D | 像素风（与 bevy-pixel-perfect-rendering 一致） |
| 5 | 导航方案 | Grid A* / Navmesh / Flow Field | Flow Field（海量敌人） |
| 6 | 编辑器 | Tiled / LDTK / 自研 | Tiled（最成熟生态） |
| 7 | Tilemap Crate | bevy_ecs_tilemap / bevy_entitiles / native | bevy_ecs_tilemap（最稳定） |
进阶决策
| # | 决策点 | 考虑因素 |
|---|---|---|
| 8 | 地形-刷怪耦合度 | 混合模式：地形提供候选 zone，刷怪系统决策 |
| 9 | Biome 数量 | 3-5 个足够（D4 也是 5 个），重点在内部变体而非数量 |
| 10 | 动态地形 | 破坏/变形是否支持？影响 tileset 设计和性能 |
| 11 | Mod 支持 | 是否需要外部地图编辑/导入？影响文件格式选择 |
12. 各游戏地形设计评分
| 维度 (1-5) | Diablo IV | PoE | Last Epoch | Grim Dawn | Lost Ark |
|---|---|---|---|---|---|
| 视觉质量 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 程序化生成成熟度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐ | ⭐⭐ |
| 独立团队可复制性 | ⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 战斗空间可读性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 环境叙事深度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 导航/AI 成熟度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 性能优化 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
SideDawn 当前实现（2026-08-26 锁）+ mosaic 地形研究
当前地形真源不是 mosaic MAPGEN-1 / generate_map / 32×32 Hybrid Zone。 SideDawn 工作仓是 crates/zonegen + zonegen::generate（FM-SD-MAPGEN-2）。三种形态 ≠ 三个世界；只有一个 CurrentZone。见 decisions。
2026-08-28 行业 mapgen pack 见 research-arpg-mapgen-practices（非决策；不是 MAPGEN-1；不把 Room Pool / 异步 bake 写成 SideDawn 锁）。
mosaic docs/research/2026-08-23-arpg-terrain-height.md（2026-08-23）：等距 ARPG 主流不是「全图整数台阶枚举」，也不是「连续 heightmap 当唯一玩法真源」。更常见是 mesh/heightmap 表现高度 + 独立 walkability / height grid / 烘焙 navmesh。高度至少拆四层（玩法 / 表现 / 作者工作流 / 与通行关系）。没有核到商业 ARPG 用「相邻格整数 level 差 ≤ N」当唯一可走规则。水几乎都有自己的通道。
docs/research/2026-08-23-arpg-tiletype-survey.md（2026-08-23）：商业 ARPG 几乎没有 {Ground, Wall, Water} 三值玩法枚举。碰巧叫 TileType 的 D1/D2 字段是几何/编码层；通行是旗标或手绘网格。墙不是「一个 Wall 值 = 整格不可走」。战斗危害是正交层。
docs/research/2026-08-22-arpg-map-edge-boundaries.md（2026-08-22）：外缘主语言是 diegetic 不可通行地形，不是矩形硬墙环。不可出界几乎全是数据层保证。雾/大气是软遮罩，不是碰撞。mosaic 硬 Wall 环是夹具史，不要提升为 sidedawn 当前。
docs/research/arpg-terrain-system.md 偏通用 heightmap LOD，不得当成 ARPG 玩法高度结论。
相关页面
- arpg-camera-perspective — ARPG 视角设计，与本文直接相承
- bevy — Bevy 引擎总览，技术栈与生态
- bevy-development-patterns — Bevy 开发模式与工程实践
- bevy-pixel-perfect-rendering — 像素完美渲染方案
- pixel-art-texture-filtering — 像素画纹理过滤深度研究
- bevy-ecs-game-type-fit — 基于 ECS 的游戏类型匹配决策
- bevy-projects — ZoOL 的 Bevy 存储库与项目级实现笔记
- voxel-rendering — 体素渲染技术总览
- bevy_voxel_world — Bevy 体素地形插件
- bevy-landmass — Bevy 导航插件（navmesh + A* + ORCA）
- navmesh — 导航网格概念
- astar-pathfinding — A* 寻路算法
- bevy-navigation-solutions — Bevy 导航方案对比
- bevy-arpg-combat-ecs — Bevy ECS 战斗系统架构，地形与战斗的集成点
- arpg-equipment-design — 装备系统设计（地形影响掉落/遭遇）
- stylized-realism-game-art — Stylized Realism 美术风格参考
- sidedawn — 产品实体；地形 SoT 在 zonegen
- research-mosaic-ingest
- research-arpg-mapgen-practices — 2026-08-28 行业 pack（非决策）