上岸的鱼

一、本章核心目标

本章的核心目标是构建一个功能完整、数据驱动且高度可扩展的物品制作系统。这一目标分为玩家直接感知的显性目标和支撑系统长期发展的隐性战略目标。

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

  1. UI集成： 在玩家主菜单中新增一个“制作”标签页，与现有的“物品栏”标签页并存。

  2. 配方展示： 以网格布局（Grid）动态展示所有玩家当前可制作的物品配方。

  3. 状态反馈： 根据玩家物品栏中的资源存量，直观地通过UI状态（如高亮/置灰）反馈某个配方是否可被制作。

  4. 制作流程： 玩家点击可制作的配方图标后，系统将播放制作进度条动画，并在完成后从玩家物品栏中扣除所需资源，同时添加新制成的物品。

  5. 信息提示 (Tooltip): 当鼠标悬停在任一配方上时，系统会显示一个详细的信息提示框，内容包括物品描述、所需资源列表（并以不同颜色标示资源是否足够）以及最终成品的基础信息。

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

  1. 数据驱动架构： 建立一个以 Primary Data Asset 为核心的配方管理系统。这使得未来新增或修改配方只需操作数据资产文件，无需修改任何蓝图或代码，极大地提升了内容迭代效率和可维护性。

  2. 模块化与可扩展性： 将制作系统的各个部分（如配方数据、UI槽位、UI容器、制作逻辑）解耦，设计成独立的模块。特别是通过引入 E_CraftingType 枚举，为未来接入不同类型的制作站（如工作台、熔炉）预留了清晰的扩展路径。

  3. 客户端-服务器(C/S)权威验证模型： 建立一套严谨的C/S通信流程。客户端负责UI展示与用户输入，但真正的制作逻辑（资源检查、扣除、物品添加）完全在服务器上权威执行，从根本上杜绝了作弊的可能性。

  4. 开发效率提升： 实现一个“管理员模式”(Admin Mode)，允许开发者在游戏内直接将任何物品（无论有无配方）添加到物品栏，极大地简化了新物品的测试流程。

  5. 未来系统联动： 为未来的“蓝图/印痕系统”(Engram System)预留接口。当前系统只展示所有配方，但其设计已为“只展示已解锁配方”的功能做好了准备。

二、系统与功能实现

本章的实现围绕着数据、UI和逻辑三个层面展开，并与前期的物品栏系统紧密耦合。

• 具体系统/功能列表:

  • 数据层 (Data Layer):

    • PDA_ItemRecipe: 核心的配方主数据资产，定义了制作一个物品所需的所有信息（如成品属性、所需资源、获得经验等）。

    • S_ItemRecipe, S_ItemRecipeInfo, S_ItemStructure: 用于在不同模块间传递制作相关数据的结构体，确保了数据格式的统一和规范。

    • E_CraftingType: 枚举类型，用于区分不同的制作环境（如玩家背包、工作台等），是系统可扩展性的关键。

  • UI层 (UI Layer):

    • W_CraftingSlot: 单个制作槽位的控件蓝图，继承自 CommonButtonBase，负责显示配方图标并处理点击事件。

    • W_CraftingContainer: 制作界面的核心容器，负责动态加载所有配方数据资产，并据此生成对应的 W_CraftingSlot 列表。

    • W_CraftingInfo & W_CraftItem: 组合构成了鼠标悬停时的信息提示框（Tooltip），前者为外框，后者为单行资源显示的子控件。

    • W_CraftingProgressBar: 独立的制作进度条控件，通过动画实现进度反馈。

  • 逻辑层 (Logic Layer):

    • 资源聚合逻辑 (GetItemQuantities): 在 BPC_ItemsContainer_Master 中实现的核心功能，能够遍历整个物品栏，将分散在不同槽位中的同种资源进行数量汇总，为制作检查提供准确数据。

    • 制作可行性检查 (CheckIfCraftable): 在UI层（客户端）和逻辑层（服务器）均有实现。客户端检查用于更新UI状态，服务器端检查用于最终的权威验证。

    • 制作执行逻辑 (CraftItem): 在服务器端执行，负责精确扣除多个物品栏槽位中的资源，并将成品添加到物品栏。

    • 管理员模式逻辑 (AddAllItems): 通过读取所有 PDA_ItemInfo 数据资产（而非配方资产）来动态生成所有物品的添加列表。

三、关键设计思想

本章的实现体现了现代游戏开发中多个重要的设计思想与原则。

• 设计模式应用:

  • 数据驱动设计 (Data-Driven Design): 这是本章最核心的设计模式。系统行为由外部数据（PDA_ItemRecipe 资产）而非硬编码逻辑决定。W_CraftingContainer 通过 AssetRegistry 的 GetAssetsByPath 函数动态发现并加载指定目录下的所有配方资产，并为之生成UI，这是该模式的典型应用。

  • 接口模式 (Interface Pattern): 大量使用蓝图接口 (BPI_SurvivalCharacter, BPI_SurvivalController) 来实现不同模块间的通信。例如，W_CraftingSlot 通过接口调用角色身上的 CraftItem 函数，而无需知道角色的具体实现类。这实现了模块间的“高内聚，低耦合”。

  • 异步加载 (Asynchronous Loading): 在加载配方和图标等资源时，普遍使用了 AsyncLoadAsset 节点。这避免了因同步加载大量资源而可能导致的瞬间卡顿，保证了UI的流畅性。

• 设计原则体现:

  • 单一职责原则 (SRP):

    • PDA_ItemRecipe 只负责存储配方数据。

    • W_CraftingContainer 只负责管理和展示制作槽位。

    • BPC_ItemsContainer_Master 中的 CraftItem 函数只负责处理资源扣除逻辑。

  • 开闭原则 (OCP):

    • 对扩展开放: 可以通过添加新的 PDA_ItemRecipe 文件来增加新配方，或通过扩展 E_CraftingType 枚举来支持新的制作台。

    • 对修改关闭: 上述扩展操作均无需修改现有已稳定的代码或蓝图。

  • 依赖倒置原则 (DIP): 高层模块（如UI层）不直接依赖底层模块（如角色逻辑），而是依赖于抽象（蓝图接口）。这使得系统的任何一部分都可以被替换或重构，而不会影响到其他部分。

四、核心技术点与难点

• 关键技术点:

  1. Asset Registry 的动态路径扫描: 利用 GetAssetsByPath 节点，实现了在运行时动态发现特定文件夹下的所有数据资产，是数据驱动架构的技术基础。

  2. C/S 完整事件流: 构建了一个从客户端UI发起，经由角色、控制器，最终在服务器上执行，再将结果同步回客户端的完整、安全的远程事件调用链。

  3. 复杂数据结构的设计与传递: 设计了 S_ItemRecipeInfo 等多个结构体，用于在Tooltip等复杂UI中精确传递和展示多源信息（如物品名、图标、当前拥有数、所需数）。

  4. UI动画与事件绑定: 使用 UMG 的动画系统制作了进度条，并通过 BindToAnimationFinished 事件，在动画播放结束后触发回调，实现了时间驱动的逻辑。

• 技术难点与解决方案:

五、自我批判与重构

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

  1. 布尔值默认值问题: 在创建 isAdminMode 和 isCrafting 两个布尔变量时，其默认值意外地为 true，导致初始逻辑判断错误，在调试后手动修正为 false。

  2. 整数除法与取模的精度: 在计算 W_CraftingContainer 的网格布局时，行列计算依赖于整数除法和取模，必须确保参与运算的变量（如每行槽位数）不为零，且逻辑正确。

  3. UI重置逻辑缺失: 最初，当一个物品槽的资源被扣减至0时，UI上仍会显示一个数量为0的图标。通过在 UpdateUI 函数中增加 ResetSlot 逻辑，才彻底清空了该槽位。

  4. Tooltip的Admin Mode兼容性: Admin模式下，物品没有配方资产，直接获取会导致空指针。通过在显示Tooltip前增加对Admin Mode的判断，规避了此问题。

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

  • 本章的设计强调了UI状态的“即时性”需求。最初的设计可能没有考虑到当玩家关闭并重新打开菜单时，制作状态需要被刷新。后续通过在 W_GameInventory 的 OnActivated 事件中调用 ResetCraftingWindow，强制将标签页重置回物品栏，确保了玩家每次打开制作页都能触发一次最新的状态检查，这是一个很好的修正。

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

  1. 简化数据流: 当前从客户端发起制作请求，到最终UI更新的事件传递链条较长（Slot -> Character -> Controller -> GameHUD -> Container -> Slot），显得有些“绕圈”。可以考虑引入一个更中心化的UI事件分发器（Event Dispatcher）或者一个轻量级的UI状态管理器，让状态更新的流向更清晰、单向。

  2. 统一检查逻辑: 客户端为了更新UI而执行的 CheckIfCraftable 和服务器为了安全验证而执行的 CheckIfCraftable 存在部分逻辑重复。可以将核心的比较算法提炼成一个纯函数（Pure Function），供两端调用，减少代码冗余。

  3. Tooltip参数优化: 向 W_CraftingInfo (Tooltip)传递了过多的独立参数（图标、名称、资源列表等）。更优的设计是只传递一个核心的 RecipeAsset 引用，由Tooltip控件自己负责从这个资产中异步加载和解析所需的所有信息，这更符合“信息隐藏”和“单一职责”的原则。

一、本章核心目标

本章节的核心在于横向扩展在第三章建立的采集系统基础，通过引入新的资源、工具和交互方式，极大地丰富了游戏的核心玩法循环，并显著提升了玩家的沉浸感与系统的可维护性。

• 显性目标 (玩家体验)

  • 丰富采集对象：引入了全新的可采集资源类型，如岩石和灌木，使世界更具互动性。

  • 扩展工具系统：新增了核心工具**“石镐”**，用于采集特定资源（如矿石），建立了工具与资源的强关联性。

  • 提升视觉反馈：为棕榈树增加了被砍伐时的撞击粒子特效 (VFX) 和被摧毁后的溶解 (Dissolve) 消失特效，增强了玩家行为的视觉反馈和沉浸感。

  • 优化库存管理：实现了物品堆叠 (Item Stacking) 功能，解决了之前采集资源会占用大量独立库存槽的问题，是核心的QoL（生活质量）提升。

  • 增加徒手采集：实现了无需工具、通过按键交互 (E键) 的徒手采集方式，用于采集灌木等地面物品。

• 隐性/战略目标 (技术与项目)

  • 验证框架可扩展性：通过添加石镐、岩石和灌木，检验了第三章建立的基于数据驱动和蓝图继承的采集框架是否足够灵活和可扩展。

  • 深化数据驱动设计：全面使用 Data Asset 来定义新的可采集资源、掉落物、工具属性等，进一步将游戏逻辑与数据分离，便于后期迭代和内容添加。

  • 建立视觉特效管线：初步建立了从材质修改（溶解）、粒子系统应用（撞击/破坏）到蓝图控制的完整VFX实现流程，为未来更复杂的特效打下基础。

  • 完善核心组件功能：对库存组件 (ItemsContainer) 进行了关键性重构，使其支持堆叠逻辑，这是任何生存建造游戏都不可或缺的核心功能。

  • 构建多模态交互：引入了基于按键的“交互系统”，与基于工具的“挥砍系统”并行，为未来更多样的互动（如开门、对话）提供了系统原型。

二、系统与功能实现

本章实现了多个关键系统，并与前期系统（如物品、库存、工具）进行了深度交互。

• 功能列表与描述

  • 溶解特效系统:

    • 通过修改 M_Palm_Master 主材质，添加了一个由标量参数 Dissolve 控制的透明度遮罩溶解效果。

    • 在 BP_PalmDestructible_Master 蓝图中，使用时间轴 (Timeline) 在树木倒地10秒后驱动该 Dissolve 参数，实现平滑的溶解动画。

  • 新工具（石镐）系统:

    • 通过复制和修改石斧的 Data Asset 和蓝图，快速创建了石镐（DA_StonePickaxe, BP_StonePickaxe）。

    • 该系统复用了父类 Tool_Master 的全部挥砍和伤害逻辑，仅需在子类中定义新的模型、工具类型（枚举）和属性。

  • 岩石采集系统:

    • 使用 Quixel Bridge 导入高精度岩石模型。

    • 创建了 BP_Rock_Master 作为所有可采集岩石的父类，并派生出具体的岩石蓝图（如 BP_Beach_Rock_01）。

    • 利用 Chaos物理引擎 的 Fracture 模式创建了几何集合体 (Geometry Collection)，用于实现岩石的破碎效果。

    • 创建了 BP_Destructible_Rock 蓝图，在被摧毁时生成破碎体，并额外生成一个 BP_Destruction_Force Actor来施加径向力，使破碎效果更真实。

  • 徒手采集（交互）系统:

    • 创建了 BP_GroundItem_Master 作为徒手采集物品（如灌木）的基类。

    • 新增了输入按键 E，并在玩家角色蓝图中实现了 F_Interact 函数，该函数执行向前射线检测，寻找实现了 BPI_Interactable 接口的Actor。

    • 如果检测到的是可徒手采集的物品，则执行 F_HarvestGroundItem 函数，播放采集动画并给予玩家资源。

  • 物品堆叠系统:

    • 重构了 BPC_ItemsContainer 中的 AddItem 函数。

    • 核心逻辑:

      1. 检查物品 Data Asset 中的布尔值，判断是否可堆叠。

      2. 若可堆叠，遍历库存寻找同ID且未满堆叠的物品。

      3. 找到则补充数量，并计算溢出量。

      4. 若有溢出或未找到可堆叠的物品，则寻找空栏位创建新堆叠。

      5. 若物品不可堆叠，则执行原逻辑（寻找空栏位）。

  • 控制器支持系统:

    • 为手柄实现了完整的UI导航，通过重写 GetDesiredFocusTarget 来设置初始焦点。

    • 实现了基于单击的“选择-放置”式物品移动（模拟拖拽） 和基于双击的快捷转移功能（如在库存和快捷栏之间转移）。

三、关键设计思想

本章的设计思想高度统一，以可扩展性和可维护性为核心。

四、核心技术点与难点

五、自我批判与重构

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

  • 破碎几何体的材质问题: Chaos破碎后的几何体，如果没有在材质中勾选Used with Geometry Collections，会出现渲染错误（如棋盘格）。 这是一个容易忽略但影响视觉效果的关键设置。

  • 控制器焦点管理: 如果不主动通过GetDesiredFocusTarget设置初始焦点，手柄在打开UI时将处于“失焦”状态，无法进行任何操作。

  • 物品堆叠的边界情况: 堆叠逻辑的复杂性很容易导致Bug，例如，对剩余数量的计算错误可能导致物品被“吞掉”或“复制”。开发过程中必须对所有可能的堆叠情景（满堆叠、部分堆叠、无堆叠、溢出）进行充分测试。

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

  • 石斧工具类型修正: 在创建石镐时，反思发现之前的石斧BP_StoneHatchet没有正确设置其ToolType枚举为Hatchet，本章对此进行了修正。 这是一个对前期疏忽的良好修正，体现了在迭代中完善系统的过程。

  • 主干蓝图的“净化”: 在创建棕榈树的子蓝图前，清空了父类Destructible_Tree_Master中的静态网格体引用。 这是一个非常好的实践，确保了父类（模板）的通用性，避免子类意外继承不必要的资产引用，从而优化内存。

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

  • 统一采集接口: 当前为大型采集物（树、矿）和地面采集物（灌木）创建了两个功能几乎完全相同的接口 (BPI_LargeItem vs BPI_GroundItem)。 如果重来，可以设计一个更为通用的BPI_Harvestable接口，内部包含一个GetRequiredToolType函数。徒手采集可以被视为需要一个特殊的“Hand”工具类型，这样就可以用一套逻辑处理所有采集行为，减少接口冗余。

  • 使用Enhanced Input实现双击: 当前在UI中模拟双击的逻辑是有效的，但属于“手摇轮子”。 Unreal Engine的Enhanced Input系统原生支持多击（Double Tap, Triple Tap）触发器。如果重来，会研究如何将这些系统级输入触发器更优雅地与UMG的事件系统结合，可能会让实现更简洁、更官方。

  • 将物品转移逻辑集中化: 目前物品转移的逻辑分散在多个地方（Player Controller处理拖拽，TransferItemHotkey函数处理双击快捷转移）。可以考虑创建一个专门的InventoryTransferManager或类似的单例/子系统，集中处理所有类型的物品转移请求，无论其来自鼠标拖拽、控制器单击还是双击。这将使得逻辑更集中，易于调试和扩展。

一、本章核心目标

本章的核心目标是构建一个功能完备的玩家快捷栏系统，并实现首个可装备的工具——斧头，以此为基础引入资源采集的核心玩法循环。这一过程不仅实现了玩家可见的功能，也为后续更复杂的装备和交互系统奠定了坚实的技术架构。

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

  1. UI实现：在游戏界面底部创建一个可视化的快捷栏UI，允许玩家放置物品。

  2. 装备功能：玩家可以将斧头等工具放入快捷栏，并通过按下对应快捷键（1-8）来装备或卸下该工具。

  3. 资源采集：玩家装备斧头后，可以对场景中的树木进行砍伐，并成功获取木材资源。

  4. 交互优化：实现快捷栏与背包之间的物品拖拽功能，方便玩家管理物品。

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

  1. 模块化设计：建立一个独立的快捷栏组件 (BPC_PlayerHotbar)，使其与角色逻辑解耦，便于维护和未来扩展。

  2. 可扩展的装备系统：创建一个可装备物品的基类 (BP_Equippable_Master)，为未来所有武器和工具（如镐、弓箭）的快速开发提供统一的框架和接口。

  3. 可扩展的采集系统：建立可收获资源的基类 (BP_Harvesting_Master) 和配套的数据资产，形成一套可扩展的资源采集框架，为后续加入矿石、草药等不同类型的资源点做好准备。

  4. 动画状态驱动：构建一个由装备状态驱动的动画系统，通过枚举 (E_EquippableState) 控制角色在不同装备下的姿态和动作，为后续多样化的武器动画打下基础。

• 目标关系图:

  graph TD
      A[快捷栏与斧头装备] --> B{显性目标};
      A --> C{隐性/战略目标};
  
      B --> B1[UI与快捷键功能];
      B --> B2[装备/卸下斧头];
      B --> B3[砍树获取资源];
      B --> B4[与背包拖拽交互];
  
      C --> C1[组件化快捷栏系统];
      C --> C2[可扩展的装备框架];
      C --> C3[可扩展的采集框架];
      C --> C4[装备驱动的动画状态机];
  
      subgraph 核心玩法循环
          B2 --> B3;
      end
  
      subgraph 系统架构
          C1 & C2 & C3 & C4;
      end

二、系统与功能实现

本章实现了多个相互关联的系统，共同构成了快捷栏、装备与初级采集的完整功能。

• 已实现系统/功能列表:

  • 快捷栏UI系统 (W_Hotbar):

    • 描述: 一个独立的UI控件，包含了8个物品槽位 (W_ItemContainerGrid) 和对应的快捷键图标 (InputActionWidget)。 该控件被添加到主HUD布局中，固定在屏幕底部。

    • 实现流程: SizeBox -> Border -> Overlay -> 多个 HorizontalBox 分层布局（上层放物品槽，下层放快捷键图标），确保结构清晰。

  • 快捷栏组件 (BPC_PlayerHotbar):

    • 描述: 继承自通用的 BPC_ItemContainer_Master，专门用于管理快捷栏的8个物品槽位的数据。 它被添加为玩家角色的一个组件，负责存储物品信息并处理逻辑。

    • 与前期系统交互:

      • 依赖: 继承并复用了前期设计的物品容器基类 (BPC_ItemContainer_Master) 的核心数据结构和功能。

      • 交互: 通过覆写 HandleSlotDrop 等函数，与背包组件 (BPC_PlayerInventory) 实现了物品转移（拖拽）的逻辑。

  • 可装备物品系统:

    • 描述: 建立了一套清晰的继承体系 (BP_Item_Master -> BP_Equippable_Master -> BP_Hatchet_Master -> BP_StoneHatchet)。 该系统负责在玩家装备物品时，在服务器上生成对应的实体Actor，并将其附加到角色骨骼的指定插槽 (Socket) 上。

    • 与前期系统交互: 依赖前期建立的数据资产系统 (PDA_ItemInfo) 来获取物品的基础信息，如模型、类型等。

  • 可收获物系统:

    • 描述: 实现了 BP_Harvesting_Master 作为所有可采集资源的基类，并创建了棕榈树 (BP_Palm_02 等) 作为其子类。 系统包含生命值、受击反馈、资源产出和被摧毁后的表现（生成可破坏物理实体）。

    • 交互: 该系统与“可装备物品系统”直接交互。当斧头的攻击范围（通过射线检测实现）命中可收获物时，触发其生命值扣减和资源产出逻辑。

• 系统交互依赖图:

  flowchart LR
      subgraph PlayerCharacter
          A[BPC_PlayerHotbar]
          B[BPC_PlayerInventory]
          C[输入处理]
          D[动画蓝图]
      end
  
      subgraph UI
          E[W_Hotbar]
          F[W_Inventory]
      end
  
      subgraph World
          G[BP_StoneHatchet Actor]
          H[BP_PalmTree Actor]
      end
  
      C -- 触发装备 --> A
      A -- 更新数据 --> E
      B -- 更新数据 --> F
      A <--> B
      E <--> F
  
      A -- 装备/卸下 --> G
      G -- 设置动画状态 --> D
      C -- 触发攻击 --> G
      G -- 射线检测 --> H
      H -- 给予资源 --> B

三、关键设计思想

本章的设计遵循了现代游戏开发的多个核心原则，确保了系统的可维护性和扩展性。

四、核心技术点与难点

本章涉及了动画、网络和物理等多个技术领域的关键实现。

• 关键技术点:

  • 动画蓝图集成:

    • 使用 Blend Poses by Enum 节点，根据 E_EquippableState 枚举变量，在动画蓝图的状态机中动态切换角色的基础姿态（例如，从默认站立切换到持斧站立）。

    • 利用 Layered Blend Per Bone 节点，实现了上下半身动画分离。这使得角色在行走或奔跑时，上半身仍能独立播放攻击（挥斧）动画，避免了“滑步”现象。

  • 动画通知 (Anim Notify):

    • 在挥斧动画蒙太奇 (AnimMontage) 的关键帧（斧头挥出的瞬间）上添加了 Anim Notify 事件。

    • 该事件触发一个精准的服务器端射线检测，用于判断攻击是否命中目标，确保了打击判定的时机与视觉表现完美同步。

  • 网络复制 (Replication):

    • 核心逻辑在服务器: 物品的装备 (Equip)、使用 (UseItem) 和伤害计算 (HarvestFoliage) 等核心逻辑均通过 Run On Server 事件在服务器上执行，保证了游戏状态的一致性和安全性。

    • 视觉表现在所有客户端: 物品的附加到手上、动画蒙太奇的播放、树木的倒塌等视觉表现，则通过 Multicast 事件同步给所有客户端，确保所有玩家都能看到一致的画面。

  • 动态Actor生成与附加:

    • 装备物品时，服务器动态生成 (Spawn Actor From Class) 物品的蓝图实例，并通过 Attach Actor to Component 将其附加到角色骨骼的预设插槽 (Socket) 上。

• 技术难点与解决方案:

五、自我批判与重构

对本章开发过程中的问题进行总结和反思，有助于提升未来开发的质量和效率。

一、核心摘要

本章详细介绍了在虚幻引擎5中构建一个模块化、可扩展的生存游戏物品栏系统的核心框架。该框架以一个名为 BPC_ItemsContainer_Master 的主Actor组件为中心，它封装了所有通用的物品管理逻辑，例如添加、堆叠、拆分和移动物品。随后，通过面向对象的继承方式，从该主组件派生出三个功能专一的子组件：BPC_PlayerInventory（玩家主背包）、BPC_HotbarComponent（快捷栏）和 BPC_StorageContainer（储物容器），这种设计极大地提高了代码的复用性和系统的可维护性。

课程首先清晰地定义了物品的数据结构，通过创建“主数据资产”（Primary Data Asset）来储存物品的静态定义（如名称、图标、类型、最大堆叠数），并利用一个自定义的结构体（Struct）S_ItemStructure来管理每个物品实例的动态数据（如物品ID、数量、当前耐久度）。在UI方面，教程系统地指导了如何利用Widget蓝图构建完整的用户界面，包括主HUD、游戏内物品栏界面、可复用的物品槽网格，并利用Common UI插件实现了跨平台（键鼠/手柄）的输入提示。最后，课程详细拆解了拖放操作的完整实现逻辑，确保了后端数据与前端UI之间的精确通信与状态同步，为后续开发更复杂的功能（如制作、装备系统）奠定了坚实的基础。

二、关键要点

• 组件化架构: 整个物品栏系统的核心是一个名为 BPC_ItemsContainer_Master 的主Actor组件，它处理所有通用的物品操作逻辑，如添加、堆叠和拆分物品。

• 专用子组件: 从主组件派生出三个子组件：BPC_PlayerInventory（玩家主背包）、BPC_HotbarComponent（快捷栏）和 BPC_StorageContainer（储物箱、熔炉等），每个子组件负责其特定领域的逻辑。

• 数据驱动设计: 采用 Primary Data Asset 来定义每种物品的静态属性，这使得物品管理和扩展变得简单高效，无需修改代码即可添加新物品。

• 动静数据分离: 使用结构体 S_ItemStructure 来存储每个物品实例的动态数据（如数量、当前耐久度），而物品的静态信息（如名称、图标）则存储在数据资产中，实现了数据的清晰分离。

• UI与逻辑解耦: 课程利用Common UI插件构建了独立的用户界面层，通过接口（Interface）和事件驱动的方式实现UI与后端物品栏组件之间的通信，确保了系统的模块化和可维护性。

• 拖放功能实现: 详细实现了完整的物品拖放逻辑，包括在同一个容器内移动物品、在不同容器间转移物品以及处理堆叠逻辑。

• 跨平台输入兼容: 通过Common UI插件的输入操作（Input Action）和相关设置，实现了UI能够根据玩家使用的设备（键盘鼠标或手柄）自动显示对应的按键提示图标。

• 动态UI生成: 物品栏和储物箱的UI格子（Slot）是动态生成的，其数量由其对应的物品容器组件（Items Container）中的变量（NumberOfSlots）决定，实现了UI与数据源的同步。

三、核心术语

• Primary Data Asset (主数据资产): 虚幻引擎中一种用于存储静态数据的资产类型。在本课程中，它被用来定义物品的固有属性，如图标、名称、描述、是否可堆叠等。

• Actor Component (Actor组件): 一种可附加到任何Actor上的可复用功能模块。本章中的物品栏系统就是作为一个组件（BPC_ItemsContainer_Master）创建的，以便能轻松地添加到玩家角色或储物箱等Actor上。

• Struct (结构体): 一种自定义的数据类型，用于将多个相关的变量组合成一个单一的单元。本章使用 S_ItemStructure 结构体来封装一个物品实例的所有动态信息，如ID、数量和当前耐久度。

• Common UI (通用UI插件): 虚幻引擎的一个官方插件，旨在帮助开发者创建更健壮、更具平台兼容性的用户界面。本章利用它来处理跨平台（如PC和手柄）的输入提示。

• Drag and Drop Operation (拖放操作): UI编程中的一个概念，允许用户通过鼠标（或手柄模拟）“抓起”一个UI元素并将其“放置”到另一个位置。本章用于在物品栏格子之间移动物品。

四、详细实现流程

物品数据结构设计

1. 创建主数据资产 DA_ItemMaster: 定义所有物品共有的静态属性，例如 ItemName（物品名称）、ItemIcon（物品图标）、bIsStackable（是否可堆叠）、MaxStackSize（最大堆叠数量）等。

2. 创建物品结构体 S_ItemStructure: 定义物品实例的动态数据，包含 ItemID（一个 FName，用于关联到对应的主数据资产）和 Quantity（数量）。

3. 配置物品容器: 在 BPC_ItemsContainer_Master 组件中，创建一个名为 Items 的数组（Array），其元素类型为 S_ItemStructure。这个数组将是存储所有物品实例的核心数据结构。数组的大小由一个整数变量 NumberOfSlots 控制。

UI构建与绑定

1. 创建物品槽 WBP_ItemSlot: 这是显示单个物品的最小UI单元。它包含一个图标（Image）和一个数量文本（Text Block）。它还需要持有两个关键变量：ItemStructure（用于存储它所代表的物品数据）和 SlotIndex（它在容器中的索引）。

2. 创建物品网格 WBP_ItemsGrid: 该控件负责动态生成并排列所有的 WBP_ItemSlot。它包含一个 Uniform Grid Panel，并在“构建时”（OnConstruct）事件中，根据传入的物品容器组件引用，循环创建相应数量的 WBP_ItemSlot 并添加到网格中。

3. 更新UI: BPC_ItemsContainer_Master 组件中创建一个名为 OnInventoryUpdated 的事件分发器。每当 Items 数组发生变化（如添加、移除物品）时，就调用此事件。WBP_ItemsGrid 则绑定该事件，一旦接收到信号，就刷新所有 WBP_ItemSlot 的显示内容。

核心物品操作逻辑：“添加物品”

“添加物品”（AddItem）是系统中最核心的函数之一，其执行逻辑非常严谨，确保了物品能够被正确地堆叠或放置到空格子中。

• 第一步：查找可堆叠的槽位。函数首先会遍历整个 Items 数组，查找是否已存在相同 ItemID 且未达到最大堆叠数量的物品槽。

• 第二步：执行堆叠。如果找到，则计算可堆叠的数量，将新物品添加到该槽位，并更新数量。如果新物品数量超出该槽位的堆叠上限，则将该槽填满后，用剩余的物品继续执行“添加物品”流程（递归或循环调用）。

• 第三步：查找空槽位。如果遍历完所有槽位都无法完成堆叠（即没有可堆叠的槽或所有物品都已堆满），函数则开始查找第一个空的槽位（ItemID 为 None 的槽）。

• 第四步：放入空槽位。如果找到空槽位，则将新物品直接放入该槽位。

• 第五步：处理无法添加的情况。如果遍历完既无法堆叠，也找不到任何空槽位，则意味着物品栏已满，添加失败。函数返回一个布尔值（Boolean）来表示操作是否成功。

核心物品操作逻辑：“拖放与移动物品”

拖放是实现物品移动、交换、合并的基础，其逻辑在UI层面（Widget）和数据层面（Component）协同完成。

• 发起拖动 (OnDragDetected): 在 WBP_ItemSlot 控件中，当鼠标在一个非空的槽位上按下并移动时触发。

  1. 创建一个 Drag and Drop Operation 对象。

  2. 将源物品槽的信息（如物品数据、源容器引用、源索引）作为“Payload”（有效载荷）存入该对象。

  3. 创建一个 WBP_DragVisual 控件（通常仅显示物品图标），作为拖动时跟随鼠标的视觉元素，并将其存入操作对象。

• 处理放置 (OnDrop): 在目标 WBP_ItemSlot 控件上释放鼠标时触发。这是逻辑最复杂的部分。

  1. 从传入的 Drag and Drop Operation 对象中获取源物品的信息。

  2. 情况一：目标槽位为空。直接将源物品数据移动到目标槽位，并清空源槽位的数据。

  3. 情况二：目标槽位物品与源物品ID相同且可堆叠。将源物品堆叠到目标物品上，处理可能超出堆叠上限的情况，并清空源槽位。

  4. 情况三：目标槽位物品与源物品ID不同（或不可堆叠）。交换源槽位与目标槽位中的物品数据。

  5. 所有操作都在后端的物品容器组件（BPC_ItemsContainer_Master）中执行，完成后调用 OnInventoryUpdated 事件来刷新UI。

核心物品操作逻辑：“拆分堆叠”

拆分通常通过特定输入（如右键拖拽）来触发。

• 发起拆分: 用户在可堆叠的物品槽上按下特定按键（如右键）并拖动。

• 显示拆分窗口: 弹出一个UI窗口（Widget），包含一个滑块（Slider）和一个确认按钮，让玩家选择要拆分的数量（1到堆叠总数-1）。

• 执行拆分:

  1. 玩家确认数量后，在源物品容器中调用一个“拆分堆叠”函数。

  2. 该函数从源槽位的物品数量中减去指定的拆分数量。

  3. 同时，函数创建一个新的、仅用于拖拽的临时物品数据（包含物品ID和被拆分出的数量）。

  4. 将这个临时物品数据打包进 Drag and Drop Operation 对象，并启动标准的拖放流程。这样，玩家鼠标上“拿”着的就是被拆分出来的新堆叠。

“添加物品”函数逻辑流程图

这个流程图详细展示了向物品栏容器中添加一个物品时，系统内部的判断和执行顺序。

graph TD

A[开始 调用 AddItem ItemID Quantity] --> B{物品可堆叠}
B -- 是 --> C{遍历所有槽 查找相同 ItemID 且未满的槽}
C -- 找到 --> D[计算可堆叠数量]
D --> E{新物品能完全放入}
E -- 是 --> F[更新该槽数量 结束]
E -- 否 --> G[填满当前槽]
G --> H[计算剩余物品数量]
H --> B[用剩余物品继续流程]
C -- 未找到 --> I{遍历所有槽 查找空槽}
B -- 否 --> I
I -- 找到 --> J[将物品放入该空槽 结束]
I -- 未找到 --> K[物品栏已满 添加失败 结束]

“处理放置(OnDrop)”核心逻辑流程图

这个流程图展示了当一个物品被拖动并放置到另一个物品槽上时，系统如何根据目标槽位的状态来决定执行哪种操作。

graph TD
    subgraph OnDrop
        Start[开始: 物品A在槽B上释放] --> GetInfo[获取A的源信息与B的目标信息];
        GetInfo --> IsTargetSlotEmpty{目标槽B为空?};
        IsTargetSlotEmpty -- 是 --> Move[移动: 将A放入B, 清空A的源槽. 结束];
        IsTargetSlotEmpty -- 否 --> IsSameItem{A与B是同种物品且可堆叠?};
        IsSameItem -- 是 --> Stack[堆叠: 将A合并到B, 清空A源槽. 结束];
        IsSameItem -- 否 --> Swap[交换: 将A与B的数据互换. 结束];
    end

Hexo 404 及 Mermaid 图表渲染问题排查记录

作为 Hexo 用户，我最近也遇到了不少恼人的问题，特别是 Mermaid 图表无法渲染以及部署后出现 404 错误。这里记录一下整个排查和解决过程，希望能给遇到类似问题的朋友一点参考。

一、Mermaid 图表渲染问题与项目重建

最初的问题是博客中的 Mermaid 图表无法正常显示。在尝试了各种插件配置和主题调整后，我决定采取最彻底的方式：重建整个 Hexo 项目。

重建过程概览：

1. 备份： 在动手前，备份了 source (文章)、_config.yml (站点配置)、_config.next.yml (Next 主题配置) 和 package.json (插件列表)。

2. 删除旧项目： 在终端中进入 blog 目录的上一级，执行 rm -rf blog。

3. 初始化新项目： 运行 hexo init blog，然后 cd blog。

4. 安装插件和主题： 重新安装了 hexo-filter-mermaid-diagrams、hexo-deployer-git 等必要插件，并克隆安装了 Next 主题。

5. 恢复配置和文章： 将备份的配置文件覆盖新生成的文件，把文章复制回 source 目录。

6. 测试： 运行 hexo clean && hexo g && hexo s。

重建后，Mermaid 图表问题依旧存在，这让我意识到问题可能不只在 Hexo 本身。

二、浏览器端排查

既然 Hexo 配置看起来没问题，我将注意力转向了浏览器。

浏览器排查步骤：

1. 无痕模式测试： 在 Chrome 或 Safari 中打开无痕窗口，访问 http://localhost:4000/。如果图表在此模式下正常显示，那问题多半是某个浏览器扩展程序（比如广告拦截插件）造成的。

2. 开发者工具控制台： 如果无痕模式也无效，那就打开开发者工具（F12 或右键“检查”），切换到“控制台”（Console）选项卡，刷新页面。仔细查看是否有红色错误信息。这些信息是前端脚本加载或执行失败的直接线索。

三、版本兼容性问题

经过反复尝试，我开始思考是否是 Hexo 及其组件的版本兼容性问题。Hexo 的生态更新较快，老版本可能无法完美支持新插件或主题的特性。最终，通过彻底重建并确保所有组件都更新到最新、相互兼容的版本，之前遇到的许多奇怪问题才得以解决。这表明，统一组件版本对于 Hexo 博客的稳定性非常重要。

四、404 错误与 new_post_name 配置

在解决了渲染问题后，部署到线上又遇到了新的 404 错误。排查发现，一个不显眼的配置项是罪魁祸首：_config.yml 中的 new_post_name。

问题根源：

• 如果 new_post_name 设置为 :category/title，Hexo 生成文章时会创建没有 .md 后缀的文件（例如 public/tech/my-article）。

• Hexo 本地服务器可以正确处理这类文件，但大多数标准 Web 服务器（如 Nginx、GitHub Pages）在收到 http://yourdomain.com/tech/my-article 这样的请求时，会因为找不到明确的 .html 文件而返回 404。

解决方案：

将 _config.yml 中的 new_post_name 修改为：

YAML

1

new_post_name: :category/:title.md

修改后，务必执行 hexo clean && hexo g 清理并重新生成所有文件，然后重新部署。 这样 Hexo 就会生成带有 .html 扩展名的文件（例如 public/tech/my-article/index.html），Web 服务器就能正常识别并提供内容了。

总结

这次 Hexo 排查经历让我学到不少：

1. 彻底重建是解决复杂环境问题的有效手段。

2. 浏览器端排查是定位前端渲染问题的关键。

3. 版本兼容性对 Hexo 博客至关重要，尽量保持各组件版本统一。

4. new_post_name 这样的小细节也能导致部署后出现大面积 404。

希望这篇记录能帮到同样在使用 Hexo 的你。

一、核心摘要

本章作为整个课程的基石，其核心任务是从零开始，利用UE 5.4的第三人称模板，搭建一个功能完备、支持多人游戏基础架构的可玩角色。内容覆盖了从项目创建、角色与摄像机设置，到实现一个包含跑、跳、蹲伏和俯卧的完整移动动画系统。同时，本章还引入了UE5最新的增强输入系统，并最终以专业的项目备份方法收尾，为后续所有复杂系统的开发奠定坚实的技术与工程化基础。

二、 本章模块详解

模块一：项目设置与管理 (Project Setup & Management)

• 本章实现：

  1. 创建项目：
     打开UE5.4，在项目浏览器中，分类选择“游戏”，然后选择“第三人称”（Third Person）模板。

  2. 配置设置：
     确保项目类型为“蓝图”（Blueprint），为项目命名并选择存储路径（建议使用英文路径）。

  3. 整理结构：
     进入编辑器后，立即在“内容浏览器”中创建 Blueprints, Animations, Maps 等文件夹，并将模板自带的文件分类归档。

  4. 备份项目：
     在备份时，先删除项目根目录下的 Intermediate 和 Saved 文件夹（但需保留 Saved/Config 文件夹），再对整个项目进行压缩。

  提示： 手动压缩备份是项目初期的好习惯，但在专业开发流程和团队协作中，普遍使用 版本控制系统，如 Git 或 SVN。

  • 与每次都完整复制项目不同，它们主要追踪每个文件的修改历史，可以随时回溯到任意版本，极大节省存储空间。
  • 正如手动备份时需要删除 Intermediate 和 Saved 等文件夹，使用 Git (通过 .gitignore 文件) 或 SVN (通过 ignore 属性) 时，也需要设置忽略这些自动生成的文件夹，只对核心资产进行版本管理。

• 正确的项目初始化可以利用模板加速开发，而规范的备份流程则是保障项目资产安全、规避风险的关键措施。

模块二：角色蓝图与摄像机 (Character Blueprint & Camera)

• 本章实现：

  1. 定位核心蓝图，后续所有角色的逻辑开发都在 BP_ThirdPersonCharacter 这个蓝图中完成。
  2. 设置视角，通过调整角色蓝图内部的 SpringArm (弹簧臂) 和 Camera (摄像机) 这两个组件的参数，来实现第三人称视角的远近和高低。

• 角色蓝图 本身是一个容器，其具体功能都是由独立的 组件“拼装” 而成，这使得功能的添加、修改或移除都非常灵活。它作为角色的核心控制中心，负责管理所有这些组件以及角色的状态数据。

模块三：输入系统 (Input System)

• 本章实现：

  1. 创建输入动作(Action)，创建一个名为 IA_Crouch 的资产来代表“蹲伏/俯卧”的意图。
  2. 映射物理按键(Mapping)，在 IMC_Default 文件中，为 IA_Crouch 绑定键盘的 X键，并为手柄的右摇杆按下 也进行绑定。
  3. 使用触发器(Trigger)，在手柄的绑定上添加“长按”(Hold)触发器，用以区分“轻按蹲伏”和“长按俯卧”。
  4. 处理输入并同步状态，在角色蓝图中，当接收到输入事件后，会修改 isProne 等状态变量。为了让这个状态变化在多人游戏中对其他玩家可见，这个 isProne 变量必须设置为“已复制”(Replicated)。

• 该模块展示了输入是功能逻辑链的起点。它不仅负责将物理操作翻译成游戏可以理解的抽象命令，更重要的是，由输入触发的状态改变（如 isProne 变量），直接引出了为了实现网络同步而必须进行的变量复制设置。

模块四：动画与移动系统 (Animation & Locomotion System)

• 本章实现：

  1. 定义状态变量，在角色蓝图中创建布尔变量，如 isCrouching 和 isProne，作为控制动画的“开关”。
  2. 创建动画素材，导入俯卧等动画，并创建 Blendspace (混合空间) 资产来平滑地融合走、跑等动作。
  3. 构建状态机，在动画蓝图中打开“状态机”，添加“Crouch”、“Prone”等新状态，并使用第一步创建的布尔变量作为连线上的“切换规则”。

• 动画蓝图负责角色所有的视觉表现。它不进行任何逻辑判断，而是持续地从角色蓝图读取状态数据（如 isCrouching 是否为真），并根据这些数据来播放对应的动画。

模块五：多人游戏基础 (Multiplayer Foundation)

• 本章实现： 在编辑器顶部“播放”按钮旁的下拉菜单中，将“玩家数量”设置为2或更多，并将“网络模式”选择为“作为监听服务器运行”(Play as Listen Server)。

• 模块作用： 提供一个内置的、无需打包即可模拟网络环境的测试平台。这使得开发者可以从项目初期就方便地测试功能在服务器和客户端上的表现。

三、核心工作流

下图清晰地展示了本章中各个核心模块之间标准的数据与指令流转过程。
其中，从“角色蓝图”到“动画蓝图”的状态数据传递 是关键一步。其实现方式是：在动画蓝图的事件图表中，通过 Try Get Pawn Owner 节点获取其拥有者（即角色本身），然后将其 类型转换（Cast To） 为我们自己的角色蓝图（如 BP_ThirdPersonCharacter），成功后就可以直接访问并读取其中的 isCrouching 等变量了。

graph LR
    subgraph A [输入系统]
        A1(物理按键被按下<br>如玩家按下C键);
    end
    subgraph B [角色蓝图]
        B1(接收输入动作<br>如“执行蹲伏”) --> B2(更新内部状态数据<br>设置 isCrouching = true);
    end
    subgraph C [动画蓝图]
        C1(读取状态数据<br>检测到 isCrouching 为 true) --> C2(切换动画状态机) --> C3(播放对应的蹲伏动画);
    end
    A1 -- 转化为输入动作 --> B1;
    B2 -- 状态数据传递 --> C1;

四、核心技术点与难点

本章涉及了构建现代多人游戏角色的多个关键技术，并解决了一些典型问题。

• 关键技术点:

  • 增强输入系统 (Enhanced Input System): 全面使用了该系统，包括创建输入动作、映射上下文，并利用触发器（Triggers）实现了复杂的输入行为（如长按和短按的区别）。

  • 动画蓝图与状态机: 深入应用了动画蓝图的状态机，通过变量绑定和转换规则来驱动复杂的 locomotion 状态切换。

  • 蓝图接口通信: 掌握了使用蓝图接口在两个独立的蓝图类之间进行安全、解耦的数据通信方法。

  • 基础网络复制: 实践了客户端到服务器的RPC调用 (Run on Server) 和复制变量 (Replicated) 的基本工作流程，这是所有多人游戏功能的基础。

• 难点与解决方案:

  • 难点1: 客户端擅自修改速度导致服务器校正“拉扯”

    • 问题: 在未实现RPC时，客户端单独修改行走速度，但服务器仍然维持旧速度，导致服务器强制将客户端位置拉回，产生视觉上的抖动和“拉扯感”。

    • 解决方案: 创建了一个 Run on Server 的RPC (CrouchOnServer)。当客户端需要改变姿态时，它会先在本地预测性地执行，然后通过RPC通知服务器。服务器接收到请求后，权威地改变该玩家的速度和状态，并将这个状态通过复制变量同步给所有其他客户端。

  • 难点2: 引擎在修改已使用的蓝图接口时崩溃

    • 问题: 当尝试为一个已在动画蓝图中被调用的蓝图接口函数添加新的输出参数时，引擎会发生崩溃。

    • 解决方案: 采用了一个有效的规避方法：首先在动画蓝图的事件图中，暂时断开对该接口函数的调用节点，编译并保存。然后回到蓝图接口，安全地添加新的输出参数，再次编译保存。最后，再回到动画蓝图，重新连接接口调用节点并处理新的输出引脚。

  • 难点3: 有限手柄按键的复用

    • 问题: 手柄按键有限，如何用一个按键实现“短按蹲伏，长按卧倒”？

    • 解决方案: 巧妙利用了增强输入系统的触发器功能。在输入映射中，为“蹲伏”绑定了默认的 Pressed 触发器，为“卧倒”绑定了 Hold and Release 触发器，并设置了1秒的持有时间阈值，从而在同一个物理按键上实现了两种不同的逻辑响应。

一、核心摘要

本笔记提炼了“UE5.4多人生存游戏开发教程”的完整学习路径与核心知识点。该教程（共22章，272讲）旨在引导开发者从一个空白项目开始，直至成功打包并发布一个功能完备的多人在线生存游戏。本笔记将按照课程的原始章节顺序，详尽地拆分每一个章节的核心学习节点，通过本文档可以快速掌握整个课程的脉络。

二、关键要点

• 贯穿始终的多人网络核心：教程从第一章便引入多人模式，所有后续系统（如部落、建筑、社交）的开发都围绕网络同步展开，并最终以专用服务器的打包和云端托管（AWS）作为终点。

• “建筑系统”是重中之重：课程对建筑系统（Chapter 9）的投入达到了惊人的30个讲座，深度涵盖了从基础放置、网格吸附到高级结构力学（如级联销毁）的全部细节，是整个教程最核心、最复杂的模块。

• 掌握数据驱动的开发思想：教程清晰地演示了如何通过创建数据资产（Data Asset）来管理物品、配方和技能信息，实现了逻辑与数据的有效分离，这是一种专业且高效的工作流程。

• 完整的“产品化”流程：与其他只侧重功能实现的教程不同，本课程的最后阶段（Chapter 20-21）完整地覆盖了从主菜单、游戏设置、Steam会话到最终打包、部署的全过程，为学习者提供了宝贵的上线经验。

• 实用技术栈的综合应用：课程中运用了UE5的诸多现代技术，例如使用程序化内容生成工具（PCG）来高效创建广袤的植被环境（Chapter 15），以及集成高级会话插件来简化Steam联机功能的实现（Chapter 12）。

三、教程学习路线图

• Chapter 1: 项目入门 (Getting Started)

  • 创建UE5.4项目与设置

  • 设置角色蓝图与第三人称摄像机

  • 搭建动画蓝图与混合空间 (Blendspace)

  • 实现跳跃、蹲伏、卧倒等角色动作

  • 添加手柄输入支持

  • 介绍多人游戏测试模式

  • 学习项目备份方法

• Chapter 2: 构建物品系统构架 (Inventory System Framework)

  • 创建物品信息的数据资产 (Item Info Data Asset)

  • 编写库存组件 (Inventory Component)

  • 搭建库存UI界面 (Widgets)

  • 实现完整的拖拽交互逻辑 (Drag and Drop)

• Chapter 3: 快捷栏与斧头装备 (Player Hotbar & Hatchet)

  • 创建热键栏UI与组件

  • 创建可装备物品的基类

  • 实现斧头的装备、挥砍动画与逻辑

  • 创建可采集的资源基类 (如树木)

  • 实现采集逻辑与UI提示

• Chapter 4: 采集系统 (Harvesting System)

  • 添加镐子、岩石等更多工具和可采集物

  • 实现地面物品的交互拾取

  • 为库存系统添加物品堆叠功能 (Item Stacking)

  • 为库存界面添加手柄导航

• Chapter 5: 制作系统 (Crafting System)

  • 创建制作配方的数据资产

  • 搭建制作界面UI，包括物品需求提示

  • 实现物品制作逻辑与进度条

• Chapter 6: 玩家属性 (Player Stats)

  • 创建玩家状态的UI显示 (HUD)

  • 实现生命、饥饿、口渴、耐力的消耗与恢复逻辑

  • 创建消耗品并实现使用功能

  • 搭建经验值与技能点系统

• Chapter 7: 印痕系统 (Endgram System)

  • 创建印痕(蓝图)的数据资产

  • 搭建印痕树UI界面

  • 实现印痕的解锁逻辑，并与制作系统关联

• Chapter 8: 护甲装备 (Armor Equipables)

  • 创建护甲槽位UI与护甲数据

  • 实现护甲的穿戴与脱下逻辑

  • 在UI中实现3D角色实时预览窗口

  • 为护甲添加伤害减免与耐久度属性

• Chapter 9: 建筑系统 (Building System)

  • 创建建筑模块的数据资产与建造预览

  • 实现网格吸附、重叠检测、结构支撑检测等核心放置逻辑

  • 制作多种建筑模块 (地基、墙、门、窗、屋顶、楼梯等)

  • 实现建筑物的伤害与级联销毁 (Collateral Damage)

  • 实现建筑物的拆除功能

• Chapter 10: 储物容器(Storage Containers)

  • 创建储物箱UI与交互逻辑

  • 制作高级制作设施 (工作台、熔炉、烹饪锅)

  • 实现设施被摧毁后掉落物品包的功能

  • 为库存添加拆分、交换等高级功能

• Chapter 11: 物品制作 (All Items / Weapons)

  • 实现远程武器：步枪、火箭筒、弓箭

  • 实现多功能近战武器：长矛 (刺击与投掷)

• Chapter 12: 部落/氏族系统 (Tribes/Clans System)

  • 搭建部落管理UI界面

  • 实现部落的创建、邀请、加入、管理等全套逻辑

  • 将建筑权限与部落系统关联

• Chapter 13: 社交系统 (Social System)

  • 实现文字聊天框 (全局与部落频道)

  • 实现玩家头顶名称标签

  • 实现近距离语音聊天功能

• Chapter 14: 开放世界地图 (Open World Map)

  • 创建大型地编关卡与主地形材质

  • 通过导入高度图来创建地形

  • 为世界添加海洋、湖泊与河流

• Chapter 15: 程序化植被 (Procedural Foliage)

  • 学习UE5的程序化内容生成工具 (PCG) 基础

  • 为不同生态区（森林、草原等）创建PCG图表

  • 实现草地的程序化生成

• Chapter 16: AI系统 (AI System)

  • 创建被动型AI (鹿)

  • 创建攻击型AI (狼)

  • 实现AI的死亡与尸体采集逻辑

• Chapter 17: 程序化刷新区 (Procedural Zones)

  • 创建AI刷新区域蓝图

  • 将可采集的PCG植被与采集系统关联

  • 实现植被的定时重生逻辑

• Chapter 18: 小地图系统 (Player Minimaps)

  • 创建游戏中的小地图与全屏大地图

  • 制作玩家死亡与重生界面

  • 实现多点重生逻辑 (在随机区域或床上重生)

• Chapter 19: 存档/读档系统 (Save/Load System)

  • 实现玩家核心数据（库存、技能等）的存档与读档

  • 实现世界中的建筑与部落信息的存档

• Chapter 20: 网络会话与前端UI (Frontend Widgets & Steam Sessions)

  • 创建主菜单、设置菜单（画质、音量、键位）

  • 实现单人游戏模式

  • 通过Steam实现游戏大厅的创建、查找与加入

• Chapter 21: 专用服务器设置与托管 (Dedicated Server Setup & Hosting)

  • 打包游戏客户端与服务器版本

  • 学习端口转发等网络基础知识

  • 使用源码版引擎进行项目编译

  • 在云服务器(AWS)上部署并运行专用服务器

• Chapter 22: 附加内容 (Bonus Content)

  • 实现游泳系统

  • 实现基于不同表面的脚步声系统

  • 实现种植系统 (Crop Plot)

四、 对比表格：课程内容复杂度分析

此表格基于课程大纲文件中的讲座数量统计，清晰地揭示了不同模块的复杂度和学习重点。