上岸的鱼

一、 本章核心目标

本章节的目标是构建完整的游戏前端体验框架，为玩家提供清晰、功能完备的入口，并为后续的多人游戏功能打下坚实的UI与系统基础。

• 显性目标 (Player-Facing Goals):

  1. 主菜单搭建: 实现玩家启动游戏后看到的第一个交互界面，包括单人游戏、多人游戏、设置和退出等核心入口。

  2. 设置菜单实现: 提供一个全面的设置中心，允许玩家自定义图像、音频和输入控制，以优化个人游戏体验。

  3. 游戏模式入口: 提供明确的单人模式和多人模式入口，允许玩家直接开始单人游戏或进入多人服务器浏览器。

  4. 游戏内菜单: 实现游戏中可随时调用的“逃生菜单”（ESC菜单），提供返回游戏、设置、返回主菜单和退出游戏等功能。

  5. 初始角色创建流程: 为首次进入游戏的玩家设计一个“出生点选择窗口”，允许玩家输入角色名并选择初始出生区域。

• 隐性/战略目标 (Technical/Project Goals):

  1. UI框架与模块化: 建立一套可复用、模块化的UI组件体系。例如，将各类设置（如图形、音频、输入）拆分为独立的Widget，便于管理和扩展。

  2. 系统解耦: 通过为菜单系统创建独立的GameMode和PlayerController，将前端UI逻辑与核心游戏逻辑进行有效隔离，降低耦合度。

  3. 引擎系统集成: 深入集成并应用虚幻引擎的核心系统，如使用Game User Settings持久化图像设置，以及利用Enhanced Input System实现运行时的按键重映射功能。

  4. 多人会话前端: 搭建支持Steam多人会话（Session）的前端界面，包括创建游戏（Host）和查找游戏（Find）的UI，为后续的网络功能提供用户操作入口。

• 目标关系图:

  graph TD
      A[<b>本章总目标: 构建完整前端体验</b>] --> B{显性目标: 玩家功能};
      A --> C{隐性目标: 技术与架构};
  
      subgraph B
          B1[主菜单 & 游戏入口]
          B2[功能全面的设置菜单]
          B3[游戏内ESC菜单]
          B4[新玩家出生流程UI]
      end
  
      subgraph C
          C1[建立模块化UI框架]
          C2[解耦菜单与游戏逻辑]
          C3[集成引擎核心系统]
          C4[实现多人会话UI基础]
      end
  
      B1 --> C4;
      B2 --> C1;
      B2 --> C3;

二、 系统与功能实现

本章节实现了一系列相互关联的前端UI系统，具体如下表所示：

三、 关键设计思想

本章的设计遵循了现代UI开发的通用原则，以确保系统的可维护性和扩展性。

• 设计模式 (Design Patterns):

  • 组合模式 (Composition): 大量使用Widget组合来构建复杂UI。例如，W_OptionsMenu由W_GraphicsSettings、W_AudioSettings等子Widget组合而成，而W_FindSession则动态组合多个W_ServerSlot来构成服务器列表。这种模式使得每个UI部分都可以独立开发和修改。

  • 观察者模式 (Observer / Event-Driven): 系统的核心交互是事件驱动的。UI控件（如按钮、滑块）的各种事件（OnClicked, OnValueChanged）是信号（Subject），而处理这些事件的蓝图逻辑则是观察者（Observer）。这种模式将UI表现与业务逻辑解耦。

• 设计原则 (Design Principles):

  • 单一职责原则 (Single Responsibility Principle, SRP): 每个Widget都聚焦于一个明确的功能。W_GraphicSetting只负责展示和响应一组（低、中、高、极高）图形选项；W_ServerSlot只负责展示一个服务器的信息。这使得代码逻辑清晰，易于定位和修改。

  • 关注点分离 (Separation of Concerns, SoC): 将UI（视图）与控制逻辑和数据（模型）分离。

    • UI与控制器分离: 菜单的显示/隐藏、输入模式的切换等高层逻辑由PlayerController负责，而Widget本身只负责内部的渲染和事件派发。

    • 菜单与游戏逻辑分离: 通过引入MainMenu_GameMode，将主菜单的规则和流程与游戏世界的核心玩法规则彻底分开。

四、 核心技术点与难点

本章节的实现涉及多个虚幻引擎的核心技术，并解决了一些具有挑战性的问题。

• 核心技术点:

  1. UMG (Unreal Motion Graphics): 深度应用UMG系统，包括但不限于各类控件的自定义样式、数据绑定 (Binding)、以及使用Widget Switcher和Scroll Box进行动态内容管理。

  2. Game User Settings API: 利用此API实现图形和视频设置的读取、应用和持久化存储。这是一个标准化的、跨平台的设置管理方案。

  3. Enhanced Input System 运行时重映射: 核心难点在于动态修改InputMappingContext。正确流程是：获取EnhancedInputLocalPlayerSubsystem，清除所有现有映射，直接修改内存中的InputMappingContext对象（设置新的按键），然后将修改后的InputMappingContext重新添加到Subsystem中。

  4. Advanced Sessions 插件应用: 熟练运用该插件替代引擎原生会话节点，实现了创建带自定义元数据（如服务器名、地图）的会话和异步查找会话的功能。

  5. 自定义SaveGame对象: 当Game User Settings不满足需求时（如音频设置），通过创建自定义的SaveGame派生类来灵活地实现数据的持久化存储。

• 技术难点与解决方案:

五、 自我批判与重构

本章节的实现虽已满足核心功能，但在设计和实践中也暴露出一些可优化之处。

• 遇到的“坑”或关键问题:

  1. 引擎版本迭代导致API变更: Enhanced Input System的按键重映射逻辑在引擎更新后发生了重大变化。旧的Unmap Key/Map Key方法失效，必须重构为直接修改InputMappingContext并重新注册的方案。

  2. 配置文件顺序问题: 在配置DefaultEngine.ini以启用Steam时，由于配置项的顺序不当（例如VoiceEnabled=true放在了OnlineSubsystem定义之上），导致Steam子系统未能正确初始化，这是一个难以发现的配置陷阱。

  3. Widget引用混淆: 在实现“出生菜单”时，错误地复用了为“重生菜单”设计的W_RespawnZone，而不是新复制的W_SpawnZone，导致逻辑不匹配。这强调了在复制和重用资产时保持清晰命名的重要性。

• 对前期设计的反思与修正:

  • 单人模式过于简化: 当前的单人模式只是一个直接加载地图的快捷方式。反思认为，一个更完善的设计应该引入一个中间UI，让玩家能够管理存档、选择地图或调整特定于单人游戏的设置，这在讲座中也有提及。

  • 缺少游戏内菜单: 前期设计中忽略了游戏进程中的暂停/菜单需求。本章通过添加ESC菜单弥补了这一核心体验的缺失，是必要的设计修正。

• 重构优化设想 (If I were to do it again):

  1. 全面采用接口通信: 当前部分UI间的通信（如图形设置按钮与其父容器）依赖于GetPlayerController后的强制类型转换 (Cast)。如果重来，会全面采用**蓝图接口（Blueprint Interface）**进行通信。这可以彻底解耦UI组件，使其不依赖于任何特定的PlayerController或父Widget，从而实现真正的“即插即用”。

  2. 引入中心化UI管理器: 当前UI的创建和销毁逻辑散布在各个触发点（如A按钮点击创建B窗口）。可以设计一个单例的UI_Manager，负责所有顶层UI面板的堆栈式管理（Push/Pop）。所有UI创建请求都发往该管理器，由它来处理显隐、层级和输入模式切换，使UI流程控制更集中、更清晰。

  3. 数据驱动UI生成: 图形设置菜单当前是在UMG编辑器中手动布局每一行。更优的方案是将其数据驱动化。可以创建一个数据表（Data Table），定义每项图形设置的名称、类型（下拉、滑块）、以及对应的GameUserSettings函数。Widget在构建时读取数据表，动态生成所有设置行。这样做将极大简化未来新增或修改图形选项的工作量。

1. 本章核心目标

本章的核心目标是构建完整的玩家地图与死亡复活体验闭环，从UI展示到核心逻辑实现，涵盖了玩家在探索与失败两种核心场景下的关键需求。

• 显性目标 (玩家导向):

  1. 实时位置追踪: 在游戏主界面右上角提供一个常驻的“小地图”（Minimap），实时显示玩家当前位置及朝向。

  2. 战术地图查阅: 允许玩家在菜单中打开一个“大地图”（Large Map），以更宏观的视角查看整个世界、兴趣点以及自己的精确位置。

  3. 死亡与复活机制: 实现玩家死亡后的完整流程，包括创建死亡惩罚（物品掉落）和提供复活选项。

  4. 多点复活选择: 玩家死亡后，可以从多个预设的“区域”（Zone）或自己放置的“床”（Bed）中选择一个作为复活点。

• 隐性目标 (技术/战略导向):

  1. 动态材质应用: 探索并实践利用材质参数集合（Material Parameter Collection）与蓝图结合，实现高效、动态的UI视觉效果，特别是用于地图的平移与缩放。

  2. 客户端/服务器(C/S)架构深化: 在死亡和复活流程中，严格划分客户端与服务器的职责。例如，死亡事件由服务器权威触发与计算，而UI展示与玩家输入则在客户端处理，并通过RPC（远程过程调用）与服务器通信。

  3. 模块化与可复用UI: 创建可复用的UI组件（如W_ZoneWidget, W_BedIcon），并通过动态生成的方式填充到父容器中，提高UI开发的灵活性与可扩展性。

  4. 系统解耦设计: 引入蓝图接口（Blueprint Interface）作为Widget与Player Controller、Character之间的通信桥梁，避免硬引用，降低系统耦合度。

• 目标关系图:

2. 系统与功能实现

本章实现了三大核心功能模块：小地图系统、大地图系统和死亡复活系统。

• 实现列表:

  1. 小地图 (Minimap):

     • MPC_Minimap (材质参数集合): 用于存储地图的X/Y偏移、缩放(Zoom)和尺寸(Dimensions)等动态参数。

     • M_Minimap (核心材质): 包含一套复杂的材质节点网络，通过读取MPC_Minimap的参数来计算并裁剪地图纹理的UV，实现地图的移动与缩放效果。

     • W_Minimap (UI控件): 在Event Tick中持续获取玩家位置和朝向，更新MPC_Minimap的参数和玩家图标的旋转，从而驱动材质变化。它还通过绑定获取在线玩家数量。

  2. 大地图 (Large Map):

     • W_MapWidget (UI控件): 一个相对简单的UI，包含完整的地图图片和一个玩家位置图标。在Event Tick中，通过将玩家世界坐标除以一个缩放系数，直接设置玩家图标在UI上的Render Transform Translation。

  3. 死亡复活系统 (Death & Respawn):

     • 死亡事件流程: 在玩家角色的Event AnyDamage后触发。服务器执行F_DeathFunction，处理取消装备、清空库存、生成BPP_DeadPlayer（尸体背包）等逻辑。 同时，通过isDead变量的RepNotify，在所有客户端触发角色模型隐藏、碰撞关闭等视觉表现。

     • BPP_DeadPlayer (尸体背包Actor): 继承自StorageContainer，用于存放玩家死亡时掉落的所有物品。它拥有一个模拟物理的骨骼网格（Ragdoll），并会在一定时间后自动销毁。

     • BP_SpawnZone (复活区域Actor): 一个放置在关卡中的体积（Box Collision），定义了玩家可以选择的随机复活区域。

     • 复活逻辑: 玩家在W_RespawnWindow选择复活点后，调用服务器上的F_RespawnPlayer函数。该函数根据选择是区域还是床，找到对应的BP_SpawnZone或床的位置，传送玩家，然后重置玩家的生命/饥饿等状态，并清空和重置UI。

• 系统交互流程图 (死亡到复活):

  sequenceDiagram
      participant C as Client (玩家客户端)
      participant S as Server (服务器)
      participant PC as PlayerController
      participant Char as PlayerCharacter
      participant RW as RespawnWidget
  
      C->>S: 玩家受到致命伤害
      S->>Char: 执行 Event AnyDamage
      Char->>Char: 调用 Death on Server (RPC)
      Note over Char,S: 服务器权威执行死亡逻辑
      Char->>S: 1. 取消装备，清空库存
      Char->>S: 2. Spawn BPP_DeadPlayer (尸体)
      Char->>S: 3. 设置 isDead = true (触发RepNotify)
      S-->>C: isDead RepNotify 同步状态
      Note over C: 隐藏角色模型，关闭碰撞
      Char->>PC: 调用 ShowDeathWidget (接口)
      PC->>RW: 创建并显示复活窗口
      C->>RW: 玩家选择复活点 (例如: West Zone 1)
      RW->>PC: SetZoneSelected (接口)
      RW->>Char: RespawnPlayer (接口, Client调用)
      Char->>Char: RespawnPlayer on Server (RPC)
      Note over Char,S: 服务器权威执行复活逻辑
      Char->>S: 1. 找到SpawnZone位置
      Char->>S: 2. SetActorLocation(传送玩家)
      Char->>S: 3. 重置玩家状态(血量等)
      Char->>S: 4. 设置 isDead = false (触发RepNotify)
      S-->>C: isDead RepNotify 同步状态
      Note over C: 恢复角色模型，开启碰撞

3. 关键设计思想

• 设计模式:

  • 接口模式 (Interface Pattern): 广泛用于UI与核心逻辑的解耦。例如，W_ZoneWidget通过BPI_SurvivalControllerInterface调用PlayerController的功能，而无需直接引用PlayerController蓝图，降低了依赖性。

  • 状态模式 (State Pattern) - 简化应用: 通过isDead布尔变量及其RepNotify函数，隐式地管理角色的“存活”与“死亡”两种状态。当状态改变时，OnRep_isDead函数自动处理与该状态相关的逻辑（如启用/禁用移动、显隐模型），实现了状态与行为的封装。

• 设计原则:

  • 单一职责原则 (Single Responsibility Principle):

    • W_Minimap 负责小地图的UI和逻辑。

    • BPP_DeadPlayer 专门负责处理玩家死亡后的物品容器和物理表现。

    • F_DeathFunction 和 F_RespawnPlayer 将死亡和复活的核心逻辑分别封装，使得主事件图更清晰。

  • 开闭原则 (Open/Closed Principle):

    • 复活系统的设计良好地体现了此原则。当需要添加新的复活区域时，只需在关卡中放置新的BP_SpawnZone Actor并配置其枚举即可，无需修改现有的复活逻辑代码。

    • 同理，添加“床复活”功能时，是在现有复活逻辑上进行扩展（增加了一个分支判断），而不是修改原有的“区域复活”代码。

4. 核心技术点与难点

• 关键技术点:

  1. 动态材质与MPC: 使用Material Parameter Collection在蓝图（特别是Event Tick）中驱动材质参数，是实现动态小地图的核心。

  2. 服务器权威的复活流程: 整个“选择复活点 -> 传送 -> 重置状态”的流程完全由服务器控制，客户端仅发送请求，保证了多人游戏下的公平性和稳定性。

  3. 动态UI生成: 复活界面中的床位图标是根据服务器传递的数据动态创建 (Create Widget) 并添加到Canvas Panel或Overlay上的，展示了程序化生成UI的能力。

  4. 所有权与部落验证: 在实现“床复活”时，设计了严谨的所有权检查逻辑。它不仅检查床是否属于玩家本人，还检查是否属于玩家所在的部落，这对于实现多人协作玩法至关重要。

• 技术难点与解决方案:

5. 自我批判与重构

• 遇到的“坑”与关键问题:

  1. 坐标轴混淆: 在实现小地图时，误将X和Y坐标的更新逻辑接反，导致地图移动方向错误。

  2. 遗漏复活后的状态重置: 初版复活逻辑只传送了玩家，但忘记了恢复其被隐藏的模型和关闭的碰撞，导致玩家“隐形”复活。

  3. 碰撞冲突: 死亡后，玩家的胶囊体碰撞仍然存在，阻挡了其他玩家的镜头和移动。

  4. 空指针错误: 在拖拽尸体背包的物品时，由于一个未初始化的变量导致了访问空指针的错误。

• 对前期设计的反思与修正:

  • 反思: 大量使用Event Tick和属性绑定（Property Binding）来更新UI，虽然实现简单，但性能开销大，尤其是在低配设备上。

  • 修正:

    • 碰撞问题: 修正了OnRep_isDead函数，在死亡时将胶囊体的碰撞通道设为Ignore，复活时再恢复。

    • 状态重置遗漏: 添加了Respawn Multicast事件，用于调用isDead = false的RepNotify，从而触发状态恢复逻辑。

    • 空指针错误: 在访问变量前添加了Is Valid节点进行判断，增加了代码的健壮性。

• 如果重来一次 (优化方案):

  • 弃用Tick更新UI: 对于小地图位置更新，可以放弃Event Tick。改为使用Set Timer by Event，以一个较低的频率（如0.1秒一次）来更新地图参数。这能显著降低持续的性能消耗，同时对玩家体验影响微乎其微。

  • 事件驱动的UI更新: 对于“在线人数”这类不频繁变动的数据，应放弃属性绑定。改为在玩家加入/退出服务器时，由GameState广播一个事件，HUD接收到事件后再更新文本，实现真正的事件驱动，避免每帧检查。

  • 建立坐标转换工具函数: 应该创建一个通用的蓝图函数库，内含一个“世界坐标转UI坐标”的纯函数。该函数接收地图的世界边界、UI控件尺寸和目标世界坐标作为输入，返回精确的UI坐标。这将取代目前使用的“魔数”，提高代码的可维护性和复用性。

1. 本章核心目标

本章节的目标分为显性与隐性两个层面，它们共同服务于构建一个动态、高性能的开放世界。

• 显性目标 (玩家体验层面):

  1. 动态AI生成: 实现一个区域系统（Zone System），当玩家进入特定区域时，动态生成AI（如鹿、狼），离开时则销毁它们，使世界显得生动且不可预测。

  2. 全场景植被采伐: 使地图上所有由程序化内容生成（PCG）的静态植被（Instanced Static Meshes）变为可采伐资源。玩家可以使用斧头砍树，或直接用手采集灌木。

  3. 资源再生: 为被采伐的植被（树木、岩石、灌木）添加重生（Respawn）逻辑，使其在一段时间后能够重新出现在世界中。

• 隐性/战略目标 (技术与项目管理层面):

  1. 性能优化:

     • AI生命周期管理: 通过区域化加载和卸载AI，避免在整个大型地图上持续运行所有AI的逻辑，极大地节省了CPU资源。

     • 动态导航网格 (Dynamic NavMesh): 采用Navigation Invokers技术，仅在AI周围动态生成导航网格，而不是预烘焙覆盖整个大地图的导航数据，显著降低了内存占用和加载时间。

     • 异步资源加载: 在采伐系统中，使用软引用（Soft References）和异步加载（Async Load）来加载被转换的蓝图Actor，避免了因同步加载大量资源而可能导致的瞬间卡顿。

  2. 系统解耦与可扩展性:

     • 通过数据驱动（Data-Driven）的方式设计采伐系统，使用数据表（Data Table）将静态网格体（Static Mesh）与其对应的可采伐蓝图（Blueprint）和资源信息关联起来，使添加新的可采伐物种无需修改核心代码，提高了系统的可扩展性。

     • 广泛使用接口（Interfaces）来降低系统间的耦合度，例如，采伐工具通过区域接口（BPI_Zone）来请求移除植被，而无需了解BP_Zone内部的具体实现。

  3. 多人游戏同步的鲁棒性:

     • 解决实例静态网格（ISM）在多人环境下的移除同步问题，特别是要确保后加入游戏的玩家能看到已经被其他玩家采伐的植被是消失状态，这是实现持久化世界体验的关键一步。

2. 系统与功能实现

本章主要实现和修改了以下几个核心系统：

3. 关键设计思想

本章的实现体现了多种优秀的设计模式与原则，确保了系统的健壮性和可维护性。

• 设计模式 (Design Patterns):

• 设计原则 (Design Principles):

4. 核心技术点与难点

5. 自我批判与重构

• 遇到的“坑”或关键问题：

  1. “幽灵”实例问题： 如上所述，初期的多播同步方案不可靠，是本章遇到的最严重的技术问题。

  2. 资源命名不一致： 数据表依赖精确的静态网格体显示名称进行查找。开发过程中因命名不规范（如Tree_01 vs Tree01）导致部分植被无法被正确识别和采伐。

  3. 几何集合体（Geometry Collection）的缩放错误： 在为岩石创建可破碎模型时，直接对场景中已经缩放过的岩石创建几何集合体，导致生成的破碎蓝图默认尺寸巨大，与原始岩石不匹配。

• 对前期设计的反思与修正：

  • ISM移除逻辑的重构： 核心修正是放弃了简单的多播方案，转而采用了更健壮的“服务器遍历所有客户端并逐个发送RPC”的模式，彻底解决了同步问题。这是一个关键的迭代优化。

• 如果重来一次，如何优化：

  1. 建立严格的命名规范： 在项目早期就应强制推行统一的资源命名规则，并使用工具进行校验，以避免因手动输入错误导致的数据关联失败。

  2. 抽象采伐逻辑为组件： 可以将“检测ISM -> 查数据表 -> 异步加载 -> 生成Actor -> 请求移除ISM”这一整套逻辑封装到一个可复用的Actor组件中。这样，无论是斧头（通过重叠）还是徒手交互（通过射线检测），都可以直接调用这个组件的功能，减少在Hatchet_Master和FirstPersonCharacter中的代码重复。

  3. 规范化基础资产制作流程： 在制作可破碎模型等衍生资产时，应规定必须基于未缩放、未旋转的原始模型（T-Pose/A-Pose）进行制作，以确保衍生资产的默认状态是标准的，避免在蓝图中进行不必要的“魔法数字”式的缩放调整。

1. 本章核心目标

本章的目标分为对玩家直接呈现的“显性目标”和项目开发层面的“隐性/战略目标”。

• 显性目标 (Player-Facing Goals):

  为游戏世界引入动态的生物，丰富玩家的生存体验。玩家可以与这些生物互动，无论是狩猎它们以获取资源，还是躲避它们的攻击以求生存。

• 隐性/战略目标 (Development & Strategic Goals):

  建立一个可扩展、模块化的AI基础框架。此框架不仅要实现当前所需的基础AI行为，还要为未来引入更多、更复杂的AI类型提供支持。同时，将AI系统与游戏的核心玩法循环（探索、战斗、采集）紧密结合。

2. 系统与功能实现

本章成功实现了两大类AI的核心功能，并通过一个共享的基类进行构建，确保了代码的复用性和可维护性。

2.1 主要系统/功能列表:

• AI基类 (BP_AI_Master):

  • 作为所有AI角色的父类，统一管理通用属性和逻辑，如 “Damageable” 标签，为子类实现具体行为提供了基础。

• 被动型AI系统 (BP_AI_Passive - 以鹿为例):

  • 简单漫游 (SimpleRoam): AI在没有外部干扰时，会在导航网格内随机选择一个可达点进行移动，移动间隙有随机时长的停顿。

  • 玩家感知与逃跑 (Flee): 利用 PawnSensing 组件，当在视野内“看到”玩家时，触发逃跑逻辑。AI会提升移动速度，并朝随机方向奔跑。

  • 逃跑冷却机制: 逃跑状态会通过计时器在30-90秒后重置，使AI恢复到简单的漫游状态，避免无限逃跑。

• 攻击型AI系统 (BP_AI_Aggressive - 以狼为例):

  • 玩家感知与追击 (ChaseTarget): 同样使用 PawnSensing 组件感知玩家，但触发的是追击逻辑。AI会锁定玩家为目标并提升速度进行追击。

  • 攻击逻辑 (AttackOnServer): 当AI移动到玩家附近时，通过 Sphere Overlap Actors 进行范围检测，若玩家在攻击范围内，则对其施加随机伤害。

  • 仇恨丢失机制 (LoseAggro): 追击状态设有10秒的计时器。如果AI持续追击但无法攻击到目标（或因其他条件），仇恨会丢失，AI返回漫游状态。

• AI死亡与资源采集系统:

  • 通用死亡逻辑: AI接受伤害，生命值降至0后触发死亡事件。死亡时启用Ragdoll物理效果，并使其碰撞体不再阻挡玩家。

  • 尸体采集: 死亡后的AI尸体拥有独立的“尸体生命值” (CorpseHP)。玩家使用带有 “HarvestTool” 标签的工具攻击尸体，会调用工具的接口函数 BPI_HarvestCorpse，根据工具伤害计算并给予玩家相应的资源（如生肉）。

  • 尸体消失: 尸体资源被采集完后，会触发一个延迟销毁机制，使尸体在5秒后从世界中移除。

2.2 与前期系统交互:

3. 关键设计思想

本章的设计体现了面向对象编程和游戏开发中的一些核心原则与模式。

4. 核心技术点与难点

本章的实现综合运用了Unreal Engine的多个核心功能，并解决了AI开发中的一些常见难点。

• 核心技术点:

  • AI导航系统: 使用 Nav Mesh Bounds Volume 为AI生成可行走区域，并利用 AI Move To 节点驱动AI向目标点移动。

  • AI感知系统 (PawnSensingComponent): 高效地实现了基于视野的AI感知功能，作为触发AI行为（逃跑或追击）的入口。

  • 网络复制 (Replication):

    • 通过 RepNotify 变量 isDead 和 Multicast RPC，确保了AI死亡时的Ragdoll效果能被所有客户端正确观察到。

    • 将所有改变游戏状态的逻辑放在服务器RPC中执行，是构建稳定多人游戏的关键。

  • 蓝图接口 (Blueprint Interface): 实现了AI与玩家工具之间的解耦通信，是不同系统间交互的推荐做法。

  • 动画蓝图与混合空间 (Animation Blueprint & Blend Space): 将AI的移动速度与动画状态（站立、行走、奔跑）动态绑定，使AI动作表现自然流畅。

• 技术难点与解决方案:

5. 自我批判与重构

本章的实现功能完善且结构清晰，但也存在一些可以优化和重构的地方。

• 遇到的“坑”或关键问题:

  1. 忘记添加标签: 忘记给AI添加 Damageable 标签，导致玩家无法对其造成伤害，这是初期调试中容易忽略的问题。

  2. 逻辑连接错误: 在死亡事件中，错误地将逻辑线连接到了 Branch 的错误引脚，导致AI生命值为0后没有正确触发死亡（Ragdoll）表现。

  3. 导航缺失: 如果场景中没有放置或正确配置 Nav Mesh Bounds Volume，AI将无法移动，这在初次设置时是一个关键步骤。

• 对前期设计的反思与修正:

  本章的设计是建立在前期伤害和物品系统之上的，交互设计（通过标签和接口）是成功的。这证明了前期将核心功能（如伤害判定、物品使用）与具体实现（玩家、AI）解耦的正确性。

• 如果重来一次，如何优化？

1. 本章核心目标

本章的核心任务是利用虚幻引擎的程序化内容生成框架（PCG），为游戏世界构建一个由多个生物群落（Pine Forest, Tropical, Grasslands）组成的、富有生机且视觉上可信的动态生态系统。

• 显性目标 (Explicit Goals):

  • 为玩家创建一个视觉丰富、层次分明的游戏世界，包含松树林、热带海滩和草原三种截然不同的地貌环境。

  • 在不同生物群落中，自动填充对应的植被（如树木、灌木）和环境道具（如岩石、浮木），提升世界的沉浸感。

  • 实现茂密的地面覆盖物，如与环境匹配的草地和落叶，使地表细节更加生动。

• 隐性/战略目标 (Implicit/Strategic Goals):

  • 技术战略： 掌握并建立一套基于PCG框架的高效、可扩展的大世界场景填充工作流。该流程旨在自动化繁琐的植被摆放工作，同时保留美术层面的宏观控制力。

  • 性能战略： 针对不同类型的资产（如稀疏的大型物体与密集的地面植被），探索并实施最优的程序化生成方案，确保在提升视觉效果的同时，维持项目的性能稳定。

  • 系统整合： 将PCG系统与项目前期的景观材质系统（Landscape Material）深度整合，利用已有的材质图层数据（Layer）作为驱动程序化生成的“笔刷”，实现数据驱动的设计。

• 目标关系图:

2. 系统与功能实现

本章主要构建了两个核心系统，它们协同工作，共同完成了多生物群落的程序化生成。

• 程序化内容生成系统 (PCG System):

  • 描述: 一个名为 PCG_IslandMap 的主PCG图表被创建，作为整个岛屿生态生成的总控中心。 该系统以关卡中的主景观（Landscape）为输入源，通过一系列规则和过滤器，在指定区域生成静态网格体（Static Mesh）。

  • 实现流程:

    1. 数据输入: 通过 Get Landscape Data 节点获取景观信息。

    2. 区域过滤: 使用 Point Filter 节点，根据景观材质上绘制的图层名称（如 “pine”）筛选出目标生物群落的生成点。

    3. 环境规则过滤: 应用一系列过滤器，如基于坡度的 Density Filter（防止树木在悬崖上生成） 和基于噪音的 Density Filter（创造自然的林间空地）。

    4. 资产多样化: 利用 Transform Points 实现随机的缩放和旋转，并在 Static Mesh Spawner 中配置多种网格体变体，增加视觉丰富度。

    5. 碰撞规避: 使用 Difference 节点，从岩石的生成点中减去树木的生成点，有效防止资产重叠。

• 程序化草地系统 (Procedural Grass System):

  • 描述: 一个独立于PCG、基于景观材质的轻量级程序化系统。它专门用于高效渲染大规模、高密度的地面覆盖物，如草地和落叶。

  • 实现流程:

    1. 为每个生物群落创建 Landscape Grass Type 资产，并在其中定义要生成的草地网格体、密度、剔除距离等参数。

    2. 在主景观材质中，添加 Landscape Grass Output 节点。

    3. 将各个 Landscape Layer Sample 节点的输出连接到 Landscape Grass Output 上对应的引脚。这样，草地的生成就完全由美工绘制的景观图层权重来控制。

• 系统交互与依赖:

3. 关键设计思想

本章的实现体现了现代化游戏开发中数据驱动和模块化设计的核心思想。

• 设计模式 (Design Patterns):

  • 策略模式 (Strategy Pattern): 针对“放置植被”这一目标，根据对象的特性（大小、密度）选择了不同的实现策略。对树木、岩石等大型稀疏物体使用PCG系统；对草地等小型密集物体使用景观草地系统。这体现了为不同场景选择最合适算法的思想。

  • 观察者模式 (Observer Pattern) (隐式): PCG系统实时“观察”着景观材质的变化。当美术师在编辑器中修改地表图层时，PCG系统会自动响应这一“通知”，实时更新植被的生成与销毁。这是一种高效的响应式、数据驱动设计。

• 设计原则 (Design Principles):

  • 单一职责原则 (Single Responsibility Principle):

    • PCG系统的职责是“放置程序化定义的、相对稀疏的大型资产”。

    • 景观草地系统的职责是“渲染高密度的地面覆盖物”。

    • PCG图表内部，处理树木和处理岩石的节点链也各自负责不同的逻辑，分工明确。

  • 组合优于继承 (Composition over Inheritance): PCG图表的构建过程完美诠释了此原则。复杂的行为是通过将许多功能单一、可复用的小节点（如Sampler, Filter, Transform）组合（Composition）而成，而非通过继承一个庞大的“生物群落基类”来实现。这种方式提供了极高的灵活性和可扩展性。

4. 核心技术点与难点

5. 自我批判与重构

本章的实现虽已功能完备，但仍有宝贵的优化空间和值得反思之处。

• 遇到的"坑"与关键问题:

  • 性能陷阱: 险些用PCG处理草地，这暴露了在选择技术方案时，必须对工具的适用场景和性能限制有清晰的认识。

  • 工作流冗余: 为不同生物群落创建PCG逻辑时，大量使用了“复制粘贴”节点图。 这种方式效率低下，且后续维护成本高，容易出错。

  • 隐性依赖: 草地系统需要手动“构建”并“重启”才能生效，这种隐藏的工作流步骤可能会在团队协作中造成困惑。

• 如果重来一次，可以如何优化？

1. 本章核心目标

本章的目标分为显性与隐性两个层面，它们共同构成了地图开发的基础。

• 显性目标 (Player-Facing Goals):

  为玩家创建一个广阔、多样化且视觉上可信的开放世界岛屿地图。这包括：

  • 具有山脉、平原、海岸线等多种地貌的复杂地形。

  • 包含松林、草原、热带、河床、沙滩等多种生物群落的无缝混合地表。

  • 拥有动态海洋、河流和湖泊的完整水体系统。

  • 一个可供玩家角色进入并进行基本交互（如建造）的关卡环境。

• 隐性/战略目标 (Technical & Project Goals):

  • 技术掌握: 熟练运用Unreal Engine的景观(Landscape)和水体(Water)系统，掌握创建复杂主材质(Master Material)的技术流程。

  • 资产整合: 建立一套高效的工作流，用于整合外部资源，如Quixel Megascans的纹理和第三方的地形高度图(Heightmap)。

  • 性能与效率: 通过使用材质实例(Material Instance)、程序化混合（如坡度遮罩）和预绘制图层导入，在保证视觉效果的同时，提升开发效率和运行性能。

  • 奠定基础: 为后续的游戏系统（如植被生成、AI寻路、任务部署等）提供一个稳定且功能完善的场景基础。

2. 系统与功能实现

本章成功实现并集成了以下关键系统：

• 模块化主材质系统 (Master Material System):

  • 描述: 创建了一个名为 M_Landscape 的主材质，其核心特点是使用了“材质属性”(Use Material Attributes)。该材质整合了松林、草原、热带、河流和沙滩五种地表层。每一层都是一个独立的材质逻辑集合，并通过 LandscapeLayerBlend 节点进行混合。

  • 交互与依赖: 此系统依赖于通过 Fab/Quixel Bridge 插件下载的PBR纹理。所有可调参数（如颜色、粗糙度、纹理缩放等）均被设置为参数，以便在材质实例 MI_Landscape 中进行非破坏性调整，这极大地提升了美术迭代效率。

• 高度图地形生成系统 (Heightmap-based Landscape Generation):

  • 描述: 绕过了耗时的手动雕刻，直接从一个免费的外部高度图文件 (.png) 导入生成了整个岛屿的基础地形结构。导入时对Z轴向的高度进行了调整（缩放至45）以获得更合适的山体陡峭度。

  • 交互与依赖: 地形的最终外观完全依赖于主材质系统的应用。同时，本章提供了预先绘制好的各生物群落的图层权重图(Layer Info)，通过导入这些权重图，快速完成了地表的绘制工作，实现了地形数据与地表外观的分离管理。

• UE原生水体系统 (UE Native Water System):

  • 描述: 启用了引擎的实验性 “Water” 插件，并使用其提供的工具创建了三种水体：

    1. Water Body Ocean: 使用样条线勾勒出整个岛屿的海岸线，形成海洋。

    2. Water Body River: 使用样条线工具在山谷中绘制出多条与海洋连接的河流。

    3. Water Body Lake & Island: 在内陆创建湖泊，并使用 Water Body Island 工具在湖泊和海洋中生成岛屿或排除水体区域。

  • 交互与依赖: 水体系统与地形系统紧密耦合。水体能自动与地形进行交互，生成海岸线的泡沫和湿润效果。水体的材质是独立的，但为了风格统一，我们对其进行了深度定制。

• 系统实现流程图:

  graph TD
      A[启用插件: Fab & Water] --> B(下载纹理与高度图);
      B --> C{创建 M_Landscape 主材质};
      C -- 使用材质属性 --> D[为每个生物群落构建材质逻辑];
      D -- LandscapeLayerBlend --> E[混合所有图层];
      F[创建新关卡 Island_Map] --> G{进入Landscape模式};
      B & G --> H[导入高度图生成地形];
      E --> I{创建 MI_Landscape 材质实例};
      H & I --> J[将材质实例应用到地形];
      J --> K[创建并导入各图层权重信息];
      K --> L{进入Water模式};
      L --> M[添加并编辑海洋、河流、湖泊];
      M --> N[定制水体材质];
      N --> O[设置GameMode与PlayerStart];
      O --> P[打包测试: 验证功能与修复Bug];

3. 关键设计思想

本章的实现过程体现了多个核心设计模式与原则，确保了系统的可扩展性和可维护性。

• 设计模式应用:

  • 原型模式 (Prototype Pattern) / 实例模式: 主材质 M_Landscape 作为“原型”，MI_Landscape 作为其实例。通过修改实例的参数来创建多样的地表效果，而无需重新编译复杂的父材质。这是UE材质工作流的核心模式，极大地提升了迭代速度和性能。

  • 策略模式 (Strategy Pattern): LandscapeLayerBlend 节点可以被看作是策略模式的实现。每个图层输入（如草原、沙滩）都是一个独立的“渲染策略”。地形绘制的权重图则决定了在地形的哪个部分应用哪种策略。这使得添加新的地表类型（新策略）变得非常简单，只需添加一个新的图层输入即可。

  • 模板方法模式 (Template Method Pattern): 主材质 M_Landscape 定义了整个材质的渲染框架（如使用材质属性，连接到最终输出），而每个具体的材质层（如松林、热带）则填充了这个框架中的具体实现细节。

• 设计原则体现:

  • 开闭原则 (Open/Closed Principle): 材质系统对修改是关闭的（不轻易改动核心 LandscapeLayerBlend 结构），但对扩展是开放的（可以轻松添加新的生物群落图层）。

  • 单一职责原则 (Single Responsibility Principle): 在材质图表中，每一组节点（如“热带层”的所有节点）都只负责一个生物群落的外观，使得图表结构清晰，易于调试。

  • 不要重复自己 (Don’t Repeat Yourself - DRY): 通过创建可复用的节点组（如纹理坐标的缩放设置被应用于多个纹理）和使用材质实例，避免了代码和设置的重复。

  • 依赖倒置原则 (Dependency Inversion Principle): 通过将材质参数化，高层模块（美术师调整的材质实例）不直接依赖于底层模块（复杂的材质着色器逻辑），而是两者都依赖于抽象（参数接口）。

4. 核心技术点与难点

本章的开发涉及了多个关键技术，并解决了若干实现难点。

• 关键技术点:

  • 程序化地貌混合:

    • 高度混合: 利用 Absolute World Position 节点的Z值（高度），结合 SmoothStep，实现了沙滩干湿分离的自动过渡效果。在特定高度以下为湿沙，以上为干沙。

    • 坡度混合: 利用 SlopeMask 节点，根据地形的陡峭程度自动混合草地和岩石材质。平坦区域显示草地，而陡峭的悬崖侧壁则显示岩石，实现了自动化绘制，效果自然。

  • 材质属性系统: 使用 Use Material Attributes 选项配合 Make/Set Material Attributes 节点，将复杂的PBR材质输出引脚（BaseColor, Roughness, Normal等）打包成单一数据线，极大地简化了材质图表的视觉复杂性，使其更易于管理。

  • 水体系统定制: 深入到水体插件的内容文件夹，通过复制而非直接修改的方式，对默认的水体材质 M_Water_Ocean 等进行参数调整，以匹配项目所需的暗色、更真实的视觉风格。

• 难点与解决方案:

5. 自我批判与重构

本章工作虽已达成目标，但仍有值得反思和优化的空间。

• 遇到的“坑”与关键问题:

  1. 水体插件的破坏性修改风险: 直接修改插件目录中的核心资产会导致所有项目受影响且在引擎升级时可能丢失。

  2. 隐藏的系统依赖: 在新地图上测试旧的建造系统时，出现了一个空指针访问的Bug。这表明新环境可能会暴露先前系统中未发现的潜在问题。

  3. 视觉接缝问题: 远近水体材质参数不一致导致了明显的视觉边界，影响了场景一体性。

  4. 工作流的“体力活”: 绘制海岸线和河流的过程是重复且枯燥的体力劳动，是效率的瓶颈。

• 反思与修正:

  • 问题1的修正: 严格遵循了“复制到项目，再修改”的最佳实践，将水体材质复制到项目 /Content 目录下再进行定制，保证了原插件的完整性和项目的独立性。

  • 问题2的修正: 快速定位了建造蓝图中的空指针问题，并通过添加 Is Valid 节点进行了防御性编程修复，增强了代码的健壮性。

  • 问题3的修正: 通过细致排查，定位到 WaterZone 并同步修改了其材质参数，体现了良好的问题排查和解决能力。

• 如果重来一次，如何优化:

  • 材质结构优化: 对于 M_Landscape，可以将每个生物群落的复杂逻辑（如松林层、热带层）封装成独立的材质函数(Material Function)。主材质图表将只包含几个函数调用节点和 LandscapeLayerBlend 节点，这将使结构更加模块化，可读性和复用性达到极致。

  • 海岸线生成自动化: 探索程序化生成海岸线样条线的可能性。例如，编写一个蓝图工具，读取地形高度数据，在指定的海拔高度（如Z=0）自动生成样条线点，从而将数小时的手动工作缩短为几秒钟的计算。

  • 参数命名规范: 建立更严格的材质参数命名规范，例如 Layer_[BiomeName]_[ParameterType]_[SpecificName]（如 Layer_Grass_Scalar_Tiling），在大团队协作中能有效避免混淆。

  • 前期风险评估: 在集成任何新插件（尤其是实验性插件）前，进行更充分的文档阅读和社区问题检索，预先检查和修改项目配置，避免开发过程中的中断。

1. 本章核心目标

本章节的核心目标是构建游戏内玩家之间进行交互的基础框架，增强社区感和多人协作体验。这些目标可分为显性和隐性两个层面。

• 显性目标 (玩家体验层面)

  1. 文本聊天系统: 为玩家提供一个可以实时交流的渠道，包括面向服务器所有人的全局聊天和仅限部落成员可见的部落聊天。

  2. 玩家名牌系统: 在玩家角色头部上方显示其名称和部落名，方便身份识别，并根据玩家关系（是否为同部落成员）以不同颜色高亮。

  3. 近距离语音聊天: 实现一种基于地理位置的语音沟通方式，玩家按下特定按键后，只有附近的玩家才能听到其语音。

• 隐性目标 (技术与战略层面)

  1. 网络架构验证: 建立并验证一套稳健的客户端-服务器(Client-Server)通信模型，用于处理实时的、非 gameplay 核心的数据交换，如聊天消息和状态更新。

  2. 系统解耦与模块化: 通过接口(Interfaces)和事件驱动，确保社交系统（聊天、语音）与玩家角色、游戏模式(Game Mode)等核心模块低耦合，易于扩展和维护。

  3. 第三方插件集成: 成功集成并使用 Advanced Sessions 和 Steam Sessions 插件，为语音聊天等高级网络功能提供底层支持，为后续的在线服务打下基础。

  4. UI与游戏状态管理: 实现游戏输入模式的无缝切换（例如，从“仅游戏”模式切换到“仅UI”模式以进行聊天输入），确保玩家在进行社交互动时不会影响游戏主循环的稳定性。

2. 系统与功能实现

本章主要实现了三大核心功能系统，它们与前期系统紧密交互。

3. 关键设计思想

本章的实现体现了多种优秀的设计思想和模式，确保了系统的可维护性和扩展性。

4. 核心技术点与难点

本章的实现涉及多个关键技术点，并成功解决了一些开发中的常见难题。

5. 自我批判与重构

在开发过程中遇到了一些问题，同时也识别出一些可优化的设计。