上岸的鱼

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. 自我批判与重构

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

1. 本章核心目标

本章的核心目标分为显性与隐性两个层面，它们共同构成了部落系统的基础框架，并为未来的多人协作玩法奠定了基础。

• 显性目标 (玩家功能实现)

  • 为玩家提供创建、加入和管理部落的基础社交功能。

  • 实现部落内的权限管理，如提升/降级成员、踢出成员。

  • 建立部落内部信息共享机制，包括部落日志（Tribe Log）和每日消息（Message of the Day）。

  • 具象化部落的共享权益，例如共享建筑的拆除权、开门权限以及重生点等。

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

  • 搭建核心多人游戏状态管理框架：通过引入自定义的 GameMode、GameState 和 PlayerState，确立了服务器权威（Server-Authoritative）的多人游戏架构。这是项目从单机功能开发向真正的网络多人游戏过渡的关键一步。

  • 建立可扩展的数据结构：设计并实现了一套完整的部落相关数据结构（Enums 和 Structs），为系统后续扩展（如部落战争、部落科技）提供了标准化的数据模型。

  • 解决唯一身份标识问题：引入“Advanced Sessions”插件，从根本上解决了之前依赖测试ID所带来的权限和所有权识别BUG，为实现可靠的多人在线功能扫清了障碍。

• 目标关系图

  下表清晰地展示了显性与隐性目标之间的支撑与实现关系：

2. 系统与功能实现

本章实现了完整的部落系统，其核心功能模块与交互流程如下：

• 具体实现系统/功能列表

  1. UI系统：

     • W_TribeWindow: 部落主界面，用于展示成员、日志和每日消息。

     • W_CreateTribe: 当玩家不属于任何部落时显示的创建界面。

     • W_TribeSwitcher: 根据玩家状态（是否在部落中）切换上述两个界面的逻辑切换器。

     • W_TribeInvite: 玩家接收到部落邀请时弹出的交互窗口。

     • W_TribeMemberSlot & W_TribeLogSlot: 用于在滚动列表中动态生成部落成员和日志条目的可复用控件。

  2. 后端逻辑系统：

     • 状态管理：在 GameState 中使用 TMap<FString, FSTribeInfo> 作为核心数据容器，以部落ID为键，高效存储和检索所有部落的详细信息。

     • 数据结构：定义了 E_TribeRank、S_TribeInfo、S_TribeMemberInfo 等一系列结构体和枚举，标准化了系统数据。

     • 权限验证：所有敏感操作（如邀请、踢人、修改MOTD）均在服务器端（PlayerController或GameState）进行权限检查（如验证玩家是否为Owner或Admin）。

  3. 系统交互：

     • 邀请与加入：通过玩家角色的服务器端射线检测（Line Trace）来识别目标玩家并发起邀请，整个流程通过接口和RPC在客户端与服务器之间传递。

     • 状态同步：当部落数据发生变更时（如新成员加入、成员被踢），GameState 会遍历部落所有在线成员，并通过RPC调用其 PlayerController 上的接口，将最新的部落信息推送给每个客户端，确保所有成员UI同步更新。

• 系统交互流程图 (以“创建部落”为例)

  Code snippet

  1 2 3 4 5 6 7 8 9 10 11 12

  graph TD A[玩家在 W_CreateTribe 输入部落名并点击创建] --> B{调用 PlayerController 接口}; B --> C[PlayerController (客户端) 调用 RPC: CreateTribeOnServer]; C --> D{PlayerController (服务器端) 执行}; D --> E[1. 验证玩家资格(是否已在部落中)]; E --> F[2. 构建 S_TribeInfo 结构体]; F --> G[3. 获取玩家的 UniqueNetID 作为 TribeID]; G --> H{4. 调用 GameState 接口: CreateNewTribe}; H --> I[GameState (服务器端) 将新的 TribeInfo 添加到 TribeMap]; I --> J{5. 调用 PlayerController RPC: UpdateTribeWindow (客户端)}; J --> K[PlayerController (客户端) 获取部落UI引用]; K --> L[6. 调用 W_TribeWindow 的更新函数，刷新UI];

3. 关键设计思想

本章的开发体现了清晰的设计模式与原则，确保了系统的可维护性和扩展性。

• 设计模式与原则应用

4. 核心技术点与难点

本章的实现涉及多个关键技术点，并解决了一些典型的多人游戏开发难题。

• 核心技术点

  1. 客户端-服务器-客户端通信模型：熟练运用了 Unreal Engine 的 RPC（Remote Procedure Call）机制。例如，客户端发起操作（如邀请），通过 “Run on Server” RPC 将请求发送到服务器，服务器处理后，再通过 “Run on Owning Client” RPC 将结果或UI更新指令发回给相关客户端。

  2. 权威服务器状态管理：将部落数据 (TribeMap) 存储在仅存于服务器和客户端的 GameState 中，所有修改逻辑均在服务器上执行，客户端只能通过RPC请求修改，确保了游戏逻辑的安全和一致性。

  3. 动态UI生成：在 W_TribeWindow 中，通过循环遍历 GameState 推送过来的部落成员和日志数组，动态创建并填充 W_TribeMemberSlot 和 W_TribeLogSlot 控件，实现了数据驱动的UI更新。

• 技术难点与解决方案

5. 自我批判与重构

在开发过程中，遇到了一些设计缺陷和实现问题，并通过反思进行了修正与重构。

• 遇到的关键问题 (“坑”)

  1. UI更新不完全：最初在“加入部落”逻辑中，只更新了新加入成员的UI，而部落中其他老成员的UI没有刷新，导致信息不同步。

  2. 硬编码ID依赖：过度依赖“testID”和“secondPlayerID”等硬编码字符串作为玩家标识，导致在模拟双客户端测试时，权限和所有权判断逻辑出现严重BUG，例如无法正确执行“离开部落”操作。

  3. 父类接口调用遗漏：在重写（Override）父类的接口事件（如 StructureDestroyed）时，忘记调用父类的同名函数 (Call to Parent Function)，导致父类中定义的基础逻辑未能执行。

• 反思与重构方案

• 如果重来一次的优化

  • 提前引入唯一ID：会在项目初期就集成 Advanced Sessions 插件或实现一套临时的唯一ID生成机制，避免后期大规模的重构和因ID问题导致的调试困难。

  • 优化建筑合并逻辑：会考虑在玩家放置建筑时，就在一个全局管理器（如GameState中的一个TMap）中注册该建筑及其所有者ID。这样在合并部落时，可以直接查询这个管理器，而无需使用高消耗的GetAllActorsOfClass，从而大幅提升性能。

1. 本章核心目标

本章的核心任务是为游戏实装一个多样化且功能丰富的可交互物品系统，涵盖了从远程武器到采集工具的多个类别。

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

  • 丰富战斗方式： 为玩家提供包括步枪、火箭筒、弓、矛在内的多种远程武器，每种武器都具备独特的射击、瞄准和装填机制，显著提升了战斗的策略性和趣味性。

  • 建立资源循环： 引入了从基础（石器）到进阶（铁器）的采集工具（石斧、石镐、铁斧、铁镐），使玩家能够高效地与世界资源进行交互，为后续的生存和建造系统奠定基础。

  • 提供初始工具： 玩家默认会生成一个石头（Rock），作为游戏初期的基础工具，引导玩家进行最基本的资源采集。

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

  • 构建可扩展的武器框架： 最大的战略目标是建立一个可复用、可扩展的武器基类（BP_WeaponAimMaster）。通过将通用的瞄准逻辑（如第三人称越肩视角、第一/三人称ADS缩放、瞄准时减速）抽象到父类中，极大地简化了未来新增远程武器的开发流程。

  • 实现模块化的动画系统： 在动画蓝图中利用 Layered blend per bone 技术，实现了上下半身动画的分离与融合。这使得角色可以在执行跳跃、蹲伏等下半身动作的同时，保持上半身的持握与瞄准姿态，提升了动画表现的真实感和流畅度。

  • 深化伤害计算系统： 建立了一个基于物理表面的精准伤害系统，能够根据命中部位（如头部、胸部）应用不同的伤害乘数，并结合护甲进行伤害减免，为游戏后期的PVP/PVE平衡性设计打下了坚实基础。

2. 系统与功能实现

本章实现的核心系统涵盖了武器、动画、伤害及弹药管理，并与前期系统紧密耦合。

3. 关键设计思想

本章的设计体现了面向对象和接口驱动的编程思想，旨在构建一个高内聚、低耦合的系统。

4. 核心技术点与难点

本章涉及多个网络同步和动画融合的关键技术，并解决了一些实现过程中的难点。

5. 自我批判与重构

本章的实现过程并非一帆风顺，暴露出一些设计上的不足和可以优化的空间。