Gameplay 框架

类的关系与生命周期

下图按“谁创建谁 / 谁拥有谁”画出框架各类，括号内是生存期。

flowchart TD
  GI["GameInstance（引擎启动→关闭，跨关卡，不复制）"] --> SS["GameInstance 子系统"]
  W["World（一张地图）"] --> GM["GameMode（仅服务器，每关卡）"]
  GM --> GS["GameState（1 个，复制）"]
  GM --> PS["PlayerState（每玩家 1 个，复制）"]
  GM --> PC["PlayerController / AIController"]
  GM --> PW["Pawn / Character"]
  PC -->|"Possess 附身"| PW
  PW --> AC["Actor 组件：碰撞、网格、移动……"]
  PC --> HUD["HUD / 相机（仅人类玩家）"]

Actor 生命周期：加载、生成与销毁

官方把 Actor 实例化分成几条路径，无论哪条，最后都走同一条销毁路径。（Actor Lifecycle）

flowchart TD
  L["从磁盘加载<br/>PostLoad"] --> I
  P["PIE 复制<br/>PostDuplicate"] --> I
  S["SpawnActor<br/>PostSpawnInitialize → PostActorCreated"] --> C["ExecuteConstruction<br/>OnConstruction（蓝图构造脚本）"]
  D["SpawnActorDeferred<br/>设置属性"] -->|FinishSpawning| C
  C --> I["PreInitializeComponents → InitializeComponent → PostInitializeComponents"]
  I --> B[BeginPlay]
  B --> E["EndPlay（Destroy、关卡切换、流出、PIE 结束、退出）"]
  E --> G["标记待回收 → GC：BeginDestroy → FinishDestroy"]

图中左侧四条入口分别是关卡加载、PIE 复制、运行时生成和延迟生成；它们汇合到组件初始化和 BeginPlay，结束时都经过 EndPlay 再由 GC 释放。要点（均出自 Actor Lifecycle）：

• PostLoad 只用于从磁盘加载的 Actor，PostActorCreated 只用于生成的 Actor，二者互斥；版本修复写在 PostLoad。
• 延迟生成 (Deferred Spawn)：属性勾了 Expose on Spawn 时使用；SpawnActorDeferred 返回一个有效但未完成的实例，先设置参数，再 FinishSpawning 从构造脚本继续，适合程序化生成。
• EndPlay 的触发来源：显式 Destroy、PIE 结束、关卡切换（无缝旅行或加载地图）、所在流送关卡卸载、生命期到期、程序退出。OnDestroyed 是遗留接口，逻辑应移到 EndPlay。
• 坑：EndPlay 不等于对象已销毁。若 s.ForceGCAfterLevelStreamedOut 为 false 且子关卡被快速重新加载，Actor 可能被「复活」，局部变量不会重置为默认值。
• 判断对象是否待销毁时，用 FWeakObjectPtr 比手动检查更干净；GC 阶段的细节见 垃圾回收与对象生命周期。

各类职责

为什么这样拆分

• 控制与表现分离：Controller 决定“做什么”，Pawn 负责“在世界中怎么呈现与运动”。Pawn 既可以由 PlayerController 附身，也可以由 AIController 附身。
• 权威与复制分离：规则（GameMode）只在权威服务器上运行，客户端拿不到它；所有人都需要看到的状态放在会复制的 GameState / PlayerState 中。
• 生命周期分层：跨关卡的东西放 GameInstance（及其子系统），每关卡的放 GameMode/GameState，每玩家的放 PlayerState。

实际项目中的用法

• 计分、倒计时、比赛阶段：规则判定写在 GameMode，结果写入 GameState 供客户端 UI 读取。
• 玩家的分数、队伍、名字：放 PlayerState；输入处理和 UI 逻辑放 PlayerController；移动、碰撞、动画放 Pawn/Character 及其组件。
• 存档、登录、在线服务（好友、会话、大厅、排行榜）：放 GameInstance 或其子系统（如在线子系统 Online Subsystem）。
• Actor 的初始化写在 BeginPlay() 而不是构造函数，见 UObject 与反射系统；每帧更新与顺序见 委托与 Tick 机制。
• 这些类大多可以用 C++、蓝图或二者结合（最常见）来定制，见 蓝图与 C++ 协作。

常见坑

• 在客户端代码里获取 GameMode：它只在服务器存在，客户端拿到的是空。客户端需要的信息应放到 GameState/PlayerState。
• 把跨关卡数据放在 GameMode 或 Pawn 上：它们随关卡或角色重生而销毁。
• GameInstance 不复制，不能用它在服务器与客户端之间同步数据。
• Actor 被 Destroy() 后，其他对象持有的 UPROPERTY 引用会被置空，使用前须检查，见 垃圾回收与对象生命周期。

GEA 的视角：Actor、组件与玩法基础系统（卷 II 17.1–17.2、17.10）

GEA 第 17 章把本页这类框架称为玩法基础系统，并从架构角度评论了 Unreal：

• 单体层次与冒泡效应：GEA 把 Unreal 的对象类层次作为"单体类层次"的经典例子，并说 Actor 类包含渲染、动画、物理、世界交互、音效、网络复制、对象创建销毁、Actor 迭代和消息广播的数据与代码，是功能"冒泡"到根类的典型。

• 分歧（并列记录）：本页依据 UE 5.8 文档把 Actor 描述为"组件的容器"，移动、渲染、位置、视角等由 Actor 组件负责，Actor 自身负责变换、生成销毁和网络复制。GEA 的描述突出 Actor 承担的子系统职责，UE5 文档的描述突出组件化。GEA 没有说明其描述对应哪个引擎版本；两种说法都保留，细节见 运行时对象模型架构。

• 组件即子系统连接：GEA 说以对象为中心的组件通常代表到某个底层子系统的连接，这正是本页"Actor 组件：碰撞、网格、移动……"的组织方式。
• 高层游戏流程：GEA 认为目标、成功失败和章节推进需要一个高层状态机（Naughty Dog 的任务图还支持并行任务），本页中 GameMode 负责规则、GameState 负责比赛阶段，是 UE 放置这类逻辑的地方（对比归纳），见 游戏世界与游戏对象。