游戏开发 on 热尘的博客

抽卡系统拆解

Mon, 31 Aug 2026 13:39:38 +0800

PS: 以原神作为参考

系统设计目的

抽卡系统旨在提供玩家良好的抽卡体验，无论是交互体验还是实际数据体验。
抽卡系统在大多数情况下与充值等服务强结合，所以需要严格保证安全性。

系统架构设计

为了保证安全性，抽卡系统的所有逻辑均应该放在服务端，只给客户端暴露最基本的调用接口。

服务端设计

首先，原神作为在线的游戏，我们需要在服务端对玩家数据进行存储，那么为了与抽卡系统进行搭配，我们需要在每个用户的数据内存下可能会有用处的数据，比如限定池的抽数、常驻池的抽数、保底情况等。

那么我们应该给客户端暴露什么接口呢，不考虑其他乱七八糟的功能的话，我认为主要的有且只有一个，就是进行一次单抽的接口，然后返回抽卡结果或者是资源不够的回退。

PS： 那么这里考虑到可能的实现，我们知道CE（cheat Engine）可以去通过注入实现数值更改，那么这里我们就可以做一个检测，如果客户端的资源审批通过了但是服务端没有，那么我们便可以初步检测作弊。

然后是服务端逻辑架构，我们希望这是一个独立的系统，并且要与别的系统进行解耦，那么首先我们按照用户ID进行基础数据的fetch，然后进行更改回调，这个主要使用了用户数据存储系统暴露的接口。

然后考虑卡池更换，在每一次热更新或者重启的时候从json里读取各种up或者卡池内容，这些不会涉及到用户差异，所以不用过多考虑。

客户端设计

我们在客户端主要应该考虑的是时序、演出、流畅的玩家体验等。

考虑用户点击抽卡按钮后的流程。

客户端进行资源检测，资源不够直接回调。
如果检测成功，那么发送请求给服务端。
服务端返回抽卡结果并且触发客户端数据更新（这样我们可以把结果与资源数据全部放在服务端更改，客户端只有一次原子操作，防作弊）
然后客户端按照服务端返回的结果加载所需的动画和素材资源（这里不需要异步操作，因为本来就是在等待进程）。
完成后播放抽卡动画，触发物品入库事件或动画。

算法逻辑设计

PS: 这里只考虑服务端流程

首先，我们知道每一个卡池在启动的时候已经实现了池子更新，那么我们只考虑随机算法实现即可。

为了保证稳定随机，我们采用分层随机的方式。

比如，数值策划给我们的数据是10%的四星概率，那么我们首先rand这一发是否是四星，然后我们再去rand实际的抽卡结果，这个分层随机保证了数值稳定。

向着星辰与深渊

Unity转UE笔记长久更新

Sat, 08 Aug 2026 14:40:15 +0800

环境配置

显然，作为vscode重度用户以及半个完美主义者，我完全忍受不了VS的低扩展性以及丑的要死的界面还有它的重量，但是vscode的C++扩展对于UE的支持就是一坨，C++扩展的intelligense会把整个UE库全部塞进去，先不说内存占用，就是内联建议都没我的copilot快，这纯扯淡，所以我们需要去自己寻找更优秀的方案。

建议参考我的上一篇文章 vscode进行UE开发配置指南

代码踩坑(长期更新)

你或许可以在我的UE学习库里找到一些代码示例。

头文件顺序

UE库在底层使用了超级多诡异的宏定义，并且在编译的时候要一层一层去展开，那么这就导致了C++没有办法去自己找到一个合理的展开顺序，所以我们需要自己对头文件进行排序，当然其实也没有那么麻烦，我们只需要保证“generate.h”头文件要在最下面就好了。

当然我们要注意一点，如果你使用了vscode的自动格式化，那么一定要去改一下规则，因为有些情况格式化会把你的头文件提前，这个上面的配置教程里有写。

类引用

在Unity的C#环境中，C#集成了一个非常优秀的定义池，不仅保证了索引速度，还有实时热更新。

但是UE的C++环境中完全没有，我们甚至不能直接去在一个C++类的头文件里包含另一个C++类的头文件，这和头文件顺序是同一个错误类型，这会导致我们的宏定义展开错乱。

所以我们的正确实现变为了先在头文件里进行要引用的类声明，然后再在.cpp文件里引入完成的头文件。

下面是代码示例：

#pragma once

#include "GameFramework/Actor.h"
#include "Actor2.generated.h"

class AActor1;//提前定义需要使用的类

UCLASS()
class IWANNABECOMEUEMASTER_API AActor2 : public AActor
{
	GENERATED_BODY()

 public:
	AActor2();

 private:
	UPROPERTY(EditAnywhere, Category = "Event Binding")
	AActor1* BoundActor;//定义类的实例
};

#include "level1/Actor2.h"
#include "level1/Actor1.h"//在使用的时候引入完整的头文件

AActor2::AActor2()
{
	PrimaryActorTick.bCanEverTick = false;
}

void AActor2::BeginPlay()
{
	Super::BeginPlay();

	UE_LOG(LogTemp, Warning, TEXT("Actor2 BeginPlay() called!"));

}

使用vscode进行UE开发指南

Sat, 08 Aug 2026 12:30:00 +0800

适用：UE 5.x 项目 + VS Code 开发，用 clangd 做代码索引/补全/报错。本文是完整配置教学 + 实战踩坑记录，按顺序做就能跑通。

为什么要用 VS Code + clangd

UE 官方标配是 Visual Studio，但用 VS Code 开发完全可行，而且更轻。核心组件是 clangd —— 一个基于 LLVM 的 C++ 语言服务器，负责补全、跳转、报错、重构提示。

clangd 有个铁律：不自己猜编译参数，全靠 compile_commands.json 喂。UE 的 UnrealBuildTool 可以一键生成这份文件，于是整条链路就是：

UE 的 UnrealBuildTool
 │ -mode=GenerateClangDatabase
 ▼
compile_commands.json ← 每个 .cpp 的完整编译命令（include 路径、宏定义、标准库）
 │
 ▼
clangd 读取 → 索引 → 补全 / 跳转 / 报错 / inlay hints

所以配置的关键就两件事：让 compile_commands.json 正确生成、让 clangd 正确读到它。

环境要求

UE 5.x（本文基于 5.8）
VS Code
VS Code 扩展：clangd（Microsoft 官方）

第一步：安装扩展

安装 clangd 扩展后，把 C/C++ 扩展的 IntelliSense 关掉，两个会打架（重复报错、吃性能）：

.vscode/settings.json：

{
 "C_Cpp.intelliSenseEngine": "disabled"
}

第二步：配置 tasks.json（重点！）

任务用来跑 UBT。这里有一个大坑（见踩坑 1），先直接抄正确配置：

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "Build Editor (Development)",
 "type": "process",
 "command": "cmd.exe",
 "args": [
 "/c",
 "E:/Epicgames/games/UE_5.8/Engine/Build/BatchFiles/Build.bat",
 "YourProjectEditor",
 "Win64",
 "Development",
 "-Project=${workspaceFolder}/YourProject.uproject",
 "-WaitMutex"
 ],
 "group": { "kind": "build", "isDefault": true },
 "problemMatcher": ["$msCompile"]
 },
 {
 "label": "Generate Clang Database",
 "type": "process",
 "command": "E:/Epicgames/games/UE_5.8/Engine/Binaries/DotNET/UnrealBuildTool/UnrealBuildTool.exe",
 "args": [
 "-mode=GenerateClangDatabase",
 "-project=${workspaceFolder}/YourProject.uproject",
 "YourProjectEditor",
 "Win64",
 "Development",
 "-OutputDir=${workspaceFolder}"
 ],
 "problemMatcher": []
 }
 ]
}

只需改三处：引擎路径、项目名（YourProject）、.uproject 路径。${workspaceFolder} 会自动展开，不用动。

第三步：生成编译数据库

Ctrl+Shift+P → Tasks: Run Task → Generate Clang Database

跑完项目根目录出现 compile_commands.json 就成功。首次大概 1 分钟（要跑 UHT）。

第四步：配置 settings.json

{
 "C_Cpp.intelliSenseEngine": "disabled",
 "editor.inlayHints.enabled": "on",
 "clangd.arguments": [
 "--compile-commands-dir=${workspaceFolder}",
 "--background-index",
 "-j=6",
 "--header-insertion=never"
 ]
}

关键项：

--compile-commands-dir：指向 compile_commands.json 所在目录（项目根），这是 clangd 找到编译数据库的钥匙
editor.inlayHints.enabled：开启 inlay hints（内联提示）——函数调用边上显示参数名、auto 显示推断类型的灰字。clangd 默认会发，但 VS Code 默认不显示，必须手动开

改完配置后：Ctrl+Shift+P → clangd: Restart language server 生效。

⚠️ 注意：不要往 clangd.arguments 里加 --inlay-hints 之类的参数——clangd 22 不认这个命令行参数，会让 clangd 直接启动失败。inlay hints 的开关就是 editor.inlayHints.enabled 这一个设置，clangd 会通过 LSP 自动发送。

日常使用规则（就一条）

你做了什么	要不要刷
改 .cpp / .h 内容	❌ clangd 自动重新解析
新增 .cpp / .h 文件	✅ 跑一次 Generate Clang Database
改 Build.cs / 模块依赖	✅ 跑一次

UE 编辑器里的 Tools → Generate Visual Studio project files 不用点——那是给 Visual Studio 生成 .sln 的，跟 clangd 无关。放着别删，以后万一要用 VS 调试还有用。

踩坑记录（全是血泪）

坑 1：任务报 `'cmd /c ...' is not recognized`

现象：

& 'cmd /c E:/.../UnrealBuildTool.exe' is not recognized as a name of a cmdlet

原因： tasks.json 写成 type: "shell" + command: "cmd /c xxx"。VS Code 的默认 shell 是 PowerShell，执行 shell 任务时会生成 & 'cmd /c ...' 参数，PowerShell 把整串当命令名，自然找不到。

解法： 任务类型改 "type": "process"，绕开 shell 解析，直接 CreateProcess 调 exe。Build.bat 是批处理不能直接被 CreateProcess 调，所以用 cmd.exe + /c 显式包一层。

坑 2：clangd 报 `'xxx.h' file not found`，但文件明明存在

现象： clangd 报找不到自己的头文件，后面跟一串"连锁反应"报错（未声明标识符之类）。

先别信任何人的"根因分析"，自己实测三步：

① 看 compile_commands.json 里这个文件的记录，确认 rsp 文件存在：

Test-Path "项目/Intermediate/Build/Win64/x64/UnrealEditor/Development/模块名/Actor1.cpp.obj.rsp"

② 用 clang-cl 按 rsp 实测语法检查：

# 关键：工作目录必须切到 compile_commands.json 里的 directory（Engine/Source）！
# rsp 里全是相对路径，目录不对引擎头文件全找不到，会误导排查
cd E:/Epicgames/games/UE_5.8/Engine/Source
clang-cl -fsyntax-only "@...Actor1.cpp.obj.rsp"

③ 直接调 clangd 复现（最接近 VS Code 里的真相）：

clangd --compile-commands-dir=F:/project/YourProject --check=F:/project/YourProject/Source/.../Actor1.cpp
# 看最后一行：All checks completed, N errors

真实案例： 曾有人（AI）分析说"clangd 解析不了嵌套 rsp 所以丢了 include 路径"，建议往 .clangd 里硬塞 -I。实测 clangd 22 完美展开嵌套 rsp，Public 路径全在，头文件根本没丢。真正报错是另外两个，见坑 3、坑 4。

教训：rsp 嵌套、路径解析这种问题，别猜，跑一遍就知道。往 .clangd 加 -I 是给健康代码贴创可贴。

坑 3：`member access into incomplete type 'class FTimerManager'`

现象： GetWorldTimerManager().SetTimer(...) 报 FTimerManager 不完整类型。

原因： 头文件（Actor.h）对 FTimerManager 只有前向声明，调用它的方法需要完整定义。

解法： cpp 里加：

#include "TimerManager.h"

这是 UE 官方标准用法，所有用 SetTimer 的 Actor 都该带。

坑 4：声明了函数却没实现 → 链接期 LNK2019

现象： clangd 不报（语法没错），但编译链接时炸。

原因： 头文件里 UFUNCTION() void TriggerEvent(); 声明了，UHT 生成的 .gen.cpp 会引用它，cpp 里却没有定义。

解法： 补实现，别留空壳：

void AActor1::TriggerEvent()
{
 UE_LOG(LogTemp, Warning, TEXT("Actor1 TriggerEvent() called!"));
 OnSomethingHappened.Broadcast();
}

坑 5：clangd 启动失败 `Unknown command line argument`

现象：

clangd.exe: Unknown command line argument '"--inlay-hints=parameters+types"'
Server crashed 5 times... The server will not be restarted

原因： clangd.arguments 里加了 clangd 22 不认的参数（比如 --inlay-hints=...），clangd 直接拒绝启动。更阴险的是：VS Code 里用户级设置和工作区设置的 clangd.arguments 数组是覆盖关系，不是合并——用户设置里残留一个残缺的数组，会把工作区里 --compile-commands-dir 等正确参数全部顶掉，导致 clangd 找不到编译数据库、引擎头文件全炸（Stats/Stats.h file not found、UE_BUILD_DEVELOPMENT 未定义等连锁报错）。

解法：

检查用户级设置（Ctrl+Shift+P → Preferences: Open User Settings (JSON)），删掉残留的 clangd.arguments
inlay hints 只需要 editor.inlayHints.enabled: "on"，clangd 22 不支持 --inlay-hints 命令行参数，别加
重载窗口后 clangd: Restart language server

诊断技巧： 当出现一坨引擎头文件连锁报错（file not found + 宏未定义）时，先怀疑 clangd 拿到的参数对不对——查看 clangd 输出面板的启动日志，里面会打印完整参数列表。

坑 6：format on save 把 include 顺序排乱，UE 宏系统连锁爆炸

现象： 代码本来好好的，某次保存后 clangd 突然报一坨引擎头文件错误：

unknown type name 'FID_Engine_Source_Runtime_Engine_Classes_GameFramework_Actor_h_11_PROLOG'
UCLASS() 展开失败 → GENERATED_BODY() 失败 → 引擎 Actor.h 解析失败 → 连锁爆炸

原因： VS Code 开启了 editor.formatOnSave，而 clangd 的格式化器默认 SortIncludes 会把 include 按字母序重排！UE 的 .generated.h 以 A 开头，被直接拎到 include 列表最前面。

UE 铁律：.generated.h 必须放在 include 列表的最后。它会 #define CURRENT_FILE_ID 指向当前文件，让本文件的 UCLASS() / GENERATED_BODY() 展开成正确的宏。顺序一乱：先定义了 Actor1 的 ID，然后 include Actor.h 时引擎的 generated.h 把 CURRENT_FILE_ID 覆盖成引擎 Actor 的 → UCLASS() 拼出 FID_Engine_..._Actor_h_11_PROLOG（不存在的宏）→ unknown type name → 连锁炸穿。

解法：

把 include 顺序改回：

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "Actor1.generated.h" // 永远在最后！

重新跑一次 Generate Clang Database（UHT 会基于当前文件重新生成 .generated.h，因为格式化也把行号弄错位了，宏名对不上）
根治：配置 .clang-format，禁止重排 include。推荐放用户级（所有项目生效），C:\Users\<你>\.clang-format：

BasedOnStyle: LLVM
Language: Cpp
IndentWidth: 4
UseTab: Always
TabWidth: 4
BreakBeforeBraces: Allman
ColumnLimit: 0
Standard: c++20
SortIncludes: Never  # 保命配置，禁止重排 include

查找优先级：项目根 .clang-format > 用户级 ~/.clang-format。某个项目想单独配就放项目根。

教训： UE 项目必须配 .clang-format 且 SortIncludes: Never，否则 format on save 会静默破坏 UE 宏系统——报错全在引擎头文件里，根本想不到是自己的 include 顺序被格式化器动了。

坑 7：配了 `.clang-format` 还是被重排？凶手是 C/C++ 扩展的 vcFormat

现象： 明明在用户级配了 SortIncludes: Never，保存文件后 include 还是被打乱（generated.h 又跑最前面），而且后面几个 include 被 clangd 标灰（unused include 提示，因为符号已被 generated.h 间接引入）。

原因： VS Code 里可能有两个格式化引擎同时在候选：

clangd 自带的 formatter（读 .clang-format，尊重 SortIncludes: Never）
C/C++ 扩展的 vcFormat（不读 .clang-format，有自己的 include 排序逻辑）

用户设置里 "C_Cpp.formatting": "vcFormat" 就是雷——当 clangd 没在跑（崩溃、没重载）或格式化 fallback 时，保存会走 vcFormat，它无视你的 .clang-format 直接按自己的规则重排 include。

解法： 用户设置里把 C/C++ 扩展的格式化引擎切换成 clangFormat：

"C_Cpp.formatting": "clangFormat"

clangFormat 模式走 clang-format 逻辑，会读 .clang-format 文件（包括用户级的），SortIncludes: Never 才会真正生效。改完重载窗口。

排查技巧： 被重排后看代码风格就知道是谁干的——vcFormat 会把大括号改成同行（Allman 变 Attach），clangd 按你的 .clang-format 来。另外如果 clangd 崩过 5 次（The server will not be restarted），格式化会静默 fallback 到 cpptools，这是最常见的触发条件。

验证流程速查

# 1. 生成/刷新编译数据库（新增文件后必跑）
# VS Code: Tasks: Run Task → Generate Clang Database

# 2. 让 clangd 全量检查单文件
clangd --compile-commands-dir=F:/project/YourProject --check=F:/project/YourProject/Source/.../你的文件.cpp

看到 All checks completed, 0 errors 就是全绿。

附录：环境备忘（实测值）

项	值
UE 引擎	`E:/Epicgames/games/UE_5.8`
clangd	22.1.3（VS 18 自带 LLVM，比 UE 首选 20.1.8 新，UBT 有警告但能用）
compile_commands 的 directory	`E:/Epicgames/games/UE_5.8/Engine/Source`
手动验证必切目录	就是上面那个，别在项目目录跑

最后提示：千万不要在UE里Refresh Vscode Project

基于DAG的任务管理系统

Fri, 26 Jun 2026 21:46:41 +0800

本文将对一个基于 $\text{DAG}$ 的任务管理系统实现详细逻辑和代码拆解。

（基于 Unity 实现）

理论基底讲解

我们知道 $\text{DAG}$ 是有向无环图，而在 $\text{DAG}$ 上可以进行拓扑排序，我们发现拓扑排序的本质就是按照节点依赖关系进行排序，所以我们便可以利用这个进行管理任何依存关系。

是的，任意依存关系，所以这个实现的任务管理系统过于底层，我们完全可以在不进行高级封装的情况下将其使用在任何有依存关系的地方。

另外，这个任务管理系统因为过于底层，所以几乎没有复杂度浪费，在不进行系统层级上的优化的情况下性能已经非常高，当然更多的还可能取决于具体实现与内存管理，但是这不会有理论复杂度的区别。

程序结构分析

classDiagram
 class TaskManager {
 +Instance TaskManager
 -tasks Dictionary~string, TaskNode~
 -activeTasks HashSet~TaskNode~
 -isLoadingTasks bool
 -_initGraphCoroutine Coroutine
 +isGraphInitialized bool
 +mainPlayer GameObject
 +AddTask(taskId, taskNode)
 +GetTask(taskId) TaskNode
 +RegisterActive(node)
 +UnregisterActive(node)
 +SaveAllTaskNodes()
 +LoadAllTaskNodes()
 +SaveTaskNode(ID)
 +LoadTaskNode(ID)
 +ReloadAndRestartTasks()
 +ClearAllTaskNodesForLoad()
 +RebuildGraphFromSave()
 +OnGoalReached(goal)
 +FinishAllActiveTasks()
 -InitTaskGraph() IEnumerator
 -StartAllReadyTasks()
 -DelayedStartReadyTasks() IEnumerator
 +Awake()
 }

 class TaskNode {
 +taskId string
 +taskName string
 +Inn int
 +Out int
 +isTaskFinished bool
 +nextNodes List~TaskNode~
 +nextNodesIds List~string~
 +taskGoals List~TaskGoal~
 +StartTask()
 +CancelTask()
 +RefreshStatus()
 +ResetForLoad()
 }

 class TaskGoal {
 +IsDone bool
 +targetScript
 }

 class GameFlowManager {
 +PlayingData PlayingData
 }

 class PlayingData {
 +TaskNodesDic Dictionary~string, (int, bool)~
 }

 TaskManager --> TaskNode : 管理
 TaskManager --> GameFlowManager : 读写存档
 TaskNode --> TaskGoal : 包含
 GameFlowManager --> PlayingData : 包含

TaskManager 脚本

按照 Unity 风格，我们习惯用一个脚本实现为单例，负责注册服务和事件。

也就是我们的 TaskManager 脚本。

我们使用这个脚本进行任务节点初始化，节点出入度的统一管理还有一些调试功能的实现。

这个脚本相当于整个系统的管理器与统一调度器。

此脚本也实现了存档功能，这重点是与存档系统合理对接然后重新初始化，不在此赘述。

以下是任务初始化流程图：

sequenceDiagram
 participant Unity as Unity Engine
 participant TM as TaskManager
 participant Tasks as tasks Dictionary
 participant Archive as GameFlowManager.PlayingData

 Note over Unity: 场景加载
 Unity->>TM: Awake()
 TM->>TM: 单例检查 + DontDestroyOnLoad
 TM->>TM: StartCoroutine(InitTaskGraph())
 
 TM->>TM: WaitForEndOfFrame x2
 Note over TM: 确保所有 TaskNode 已注册
 
 TM->>Tasks: 遍历 tasks 字典
 
 loop 每个任务
 TM->>Tasks: SaveTaskNode(key) ← 初始存档
 TM->>TM: 构建 nextNodes 连接
 TM->>Tasks: targetTask.Inn++
 TM->>Tasks: taskNode.Out++
 end
 
 TM->>Archive: LoadAllTaskNodes()
 Note over TM,Archive: 恢复存档中的 Inn / isFinished
 
 TM->>TM: isGraphInitialized = true
 
 TM->>TM: StartAllReadyTasks()
 Note over TM: 启动 入度≤0 且 未完成 的任务

（注：这里的 GameFlowManager 是游戏流程管理器，这里主要负责游戏数据的对接）

TaskNode 脚本

这个脚本实现了 TaskNode 类，作为 $\text{DAG}$ 的节点实例化.

结构图：

classDiagram
 class TaskNode {
 +taskName string
 +taskId string
 +nextNodesIds List~string~
 +taskEffects List~TaskEffect~
 +taskEndEffects List~TaskEffect~
 +taskGoals List~TaskGoal~
 +nextNodes List~TaskNode~
 +Out int
 -In int
 +isTaskFinished bool
 -_taskCts CancellationTokenSource
 -isTaskRunning bool
 -isCompleting bool
 +Inn int (property)
 +Awake()
 +OnDestroy()
 +StartTask()
 +CancelTask()
 +ResetForLoad()
 +RefreshStatus()
 -OnTaskSuccess()
 -StartTaskAsync() UniTaskVoid
 +OnDrawGizmos()
 }

 class TaskEffect {
 +ApplyEffect()
 +RevertEffect()
 }

 class TaskGoal {
 +IsDone bool
 }

 class TaskManager {
 +AddTask()
 +SaveTaskNode()
 +RegisterActive()
 +UnregisterActive()
 +IsGraphInitialized bool
 }

 TaskNode --> TaskEffect : 包含
 TaskNode --> TaskGoal : 包含
 TaskNode --> TaskManager : 注册/通知

我们在这里实现对于任务节点的信息存储（如：出度，入度，任务效果，任务目标等），也实现了任务节点的启动逻辑，结束逻辑。

为了便于解耦，我们的任务流程使用 Unitask 实现，Unitask 是一个更优秀的异步库，可以便携地对异步函数进行取消，异常处理等操作。

以下是 TaskNode 对象的生命周期流程图：

stateDiagram-v2
 [*] --> 未注册: 对象实例化
 未注册 --> 已注册: Awake()
TaskManager.AddTask()
 已注册 --> 等待中: InitTaskGraph
入度 > 0
 
 等待中 --> 运行中: Inn--
Inn ≤ 0 && 未完成
 已注册 --> 运行中: StartAllReadyTasks()
Inn ≤ 0 && 未完成
 
 运行中 --> 已完成: RefreshStatus()
全部 Goal.IsDone == true
 运行中 --> 已取消: CancelTask()
(读档/场景切换)
 
 已完成 --> [*]: OnTaskSuccess()
保存存档 + 通知后继
 
 已取消 --> 已注册: ResetForLoad()
(读档调用)
 
 state 运行中 {
 [*] --> 应用开始效果: ApplyEffect()
 应用开始效果 --> 轮询检查: RefreshStatus()
 轮询检查 --> 已完成: 全部完成
 轮询检查 --> 继续等待: 未完成
 继续等待 --> 轮询检查: UniTask.Delay(250ms)
 }

以下是 TaskNode 的运行逻辑流程图：

sequenceDiagram
 participant Caller as 外部/Inn Setter
 participant TN as TaskNode
 participant TM as TaskManager
 participant Effects as TaskEffects
 participant Goals as TaskGoals

 Caller->>TN: StartTask()
 TN->>TN: CancelTask() (清理旧任务)
 TN->>TN: 创建新 CancellationTokenSource
 TN->>TN: isTaskRunning = true
 TN->>TM: RegisterActive(this)

 Note over TN: StartTaskAsync() 开始

 TN->>Effects: ApplyEffect() (开始效果)

 TN->>TN: RefreshStatus() (初始检查)
 
 loop 每 250ms
 TN->>Goals: 遍历检查 IsDone
 alt 全部完成
 TN->>TN: OnTaskSuccess()
 else 未完成
 TN->>TN: UniTask.Delay(250ms)
 end
 end

 Note over TN: OnTaskSuccess() 触发

 TN->>TM: SaveTaskNode(taskId)
 TN->>Effects: RevertEffect() (还原开始效果)
 TN->>Effects: ApplyEffect() (应用结束效果)
 
 loop 每个后继节点
 TN->>TN.nextNodes: node.Inn-- (通知后继)
 end
 
 TN->>TM: UnregisterActive(this)
 TN->>TN: CancelTask() (停止异步)
 TN->>TN: isTaskRunning = false

TaskEffect,TaskGoal,TaskBasic 脚本

TaskEffect 和 TaskGoal 脚本都是作为纯粹的数据类存在，为了可以在 Inspector 中序列化方便配置而存在。

需要注意的是，这两个脚本都强烈跟游戏的数据管理系统结合，所以并无很大的参考价值。

而 TaskBasic 则是为了自定义 TaskGoal 和 TaskEffect 而存在的基类，TaskBasic 中定义了自定义脚本的基本实现规则和属性，确保自定义脚本实现方便并且使用安全。

附录