第 7 章：Ability 生命周期与异步任务#

导入#

上一章已经让 Tag、Attribute 和 Effect 拥有了明确来源与生命周期。但一次火球术并不是同步执行到底的函数。它可能等待：

施法动画到达释放帧；
玩家确认目标或松开输入；
服务器接受或拒绝请求；
投射物命中、超时或被销毁；
角色被眩晕、死亡或主动取消；
收招动画结束。

假设玩家连续释放两次火球，第一次的动画事件迟到，第二次已经开始；如果回调只知道“Fireball Cast Point 到了”，它就可能错误地为第二次施法生成投射物。

因此，异步步骤必须绑定到一次明确的 Ability 生命周期，并在取消后彻底失效。等待完成、取消、超时、服务器拒绝和对象销毁，都只能让这次执行收束一次。

7.1 四个层次#

7.1.1 Ability Definition#

Definition 保存火球术的静态规则：

1
AbilityId = Ability.Fireball
2
Mana Cost = 30
3
Cooldown = 2 秒
4
Direct Damage = 120
5
Burning = 5 秒，Period = 1 秒
6
Blocked Tags = State.Dead / State.Stunned / State.Silenced

它可以由多个角色共享，不能保存当前目标、等待中的动画或本次 RequestId。

7.1.2 AbilitySpec#

1
public sealed class AbilitySpec
2
{
3
    public AbilitySpecHandle Handle { get; init; }
4
    public AbilityDefinition Definition { get; init; }
5
    public int Level { get; init; }
6
    public EntityId GrantedBy { get; init; }
7
    public AbilityInputBinding Input { get; init; }
8
    public AbilityConcurrencyPolicy Concurrency { get; init; }
9
}

它回答：

1
这个角色是否拥有 Ability.Fireball？
2
由什么来源授予？
3
等级和输入绑定是什么？
4
是否允许并发激活？

AbilitySpec 的生命周期通常从授予持续到撤销。它不是一次施法对象，因此不应该保存某次投射物、某次 Task 或当前取消原因。

7.1.3 AbilityRuntime#

一次激活创建一个 AbilityRuntime。它保存本次执行的可变状态：

1
ExecutionId
2
AbilitySpecHandle
3
当前生命周期状态
4
是否已经 Commit
5
本次 TargetData
6
RequestId / PredictionKey（如适用）
7
正在运行的 Ability Task
8
临时 Tag 与输入锁句柄
9
取消或结束原因
10
本次执行创建的预测记录

7.1.4 Execution Context#

Execution Context 把 AbilityRuntime 需要的依赖显式传入，而不是让它到处查找全局单例。

1
public sealed class AbilityExecutionContext
2
{
3
    public CombatRuntime Source { get; init; }
4
    public IAbilityRuleService Rules { get; init; }
5
    public IEffectApplicationService Effects { get; init; }
6
    public IGameplayEventRouter Events { get; init; }
7
    public IGameplayCueSink Cues { get; init; }
8
    public ICombatClock Clock { get; init; }
9
    public ITargetResolver Targets { get; init; }
10
}

这些接口都是本文自定义边界。AbilityExecutionContext 不是 Unity 的 Context API，也不要求项目使用依赖注入框架。

上下文应该提供规则能力，不应直接暴露所有场景对象。例如 Ability 可以请求解析 TargetData，但不应在纯 C# 核心中调用 GameObject.Find。

7.2 Ability 状态机#

7.2.1 四个核心状态#

本文使用以下状态：

1
Activating
2
  -> 正在建立本次执行并完成激活检查
3

4
Running
5
  -> 激活成立，正在执行同步步骤或等待 Task
6

7
Cancelling
8
  -> 已停止接受正常推进，正在释放本次执行资源
9

10
Ended
11
  -> 生命周期关闭，不再接受任何 Task 或 Event

状态迁移如下：

1
              +----------------------+
2
              |                      v
3
Activating -> Running -> Cancelling -> Ended
4
    |            |                       ^
5
    |            +-----------------------+
6
    +------------------------------------+

具体路径包括：

1
Activating -> Running
2
  激活检查通过，开始执行
3

4
Activating -> Ended
5
  激活前失败，尚未建立需要取消的资源
6

7
Activating -> Cancelling -> Ended
8
  已创建临时状态后发生拒绝或取消
9

10
Running -> Ended
11
  正常完成
12

13
Running -> Cancelling -> Ended
14
  被打断、超时、主动取消或服务器拒绝

有些实现会增加 Created、Waiting、Committed 或 Completing 等状态。可以增加，但不能用更多枚举掩盖职责不清。本章的四态模型已经足以建立外层生命周期。

7.2.2 Commit 是里程碑，不是生命周期终态#

Commit 回答“成本与冷却是否已经正式提交”，不回答“Ability 是否仍在运行”。

因此，AbilityRuntime 可以同时处于：

1
State = Running
2
Committed = true

火球术采用前文约定：

1
服务器验证完成
2
  -> Commit Mana 30 与 Cooldown 2 秒
3
  -> 生成权威投射物
4
  -> 等待命中或超时

投射物飞行期间，Ability 仍然 Running。即使最终打空，已经 Commit 的 Mana 和冷却通常保留。Ability Ended 后，冷却 Effect 也继续到自身 2 秒到期。

7.2.3 生命周期入口需要单向#

核心入口可以保持很少：

1
public interface IAbilityRuntime
2
{
3
    AbilityRuntimeState State { get; }
4
    bool IsCommitted { get; }
5

6
    AbilityStartResult Start();
7
    void Cancel(AbilityEndReason reason);
8
    void End(AbilityEndReason reason);
9
}

Start 只能从 Activating 推进，Cancel 只能把未结束实例带入 Cancelling，End 负责最终关闭。任何外部系统都不应直接给 State 赋值。

7.3 一次激活的执行骨架#

一个简化的激活流程如下：

1
1. 根据 AbilitySpec 创建 AbilityRuntime
2
2. 分配 ExecutionId
3
3. 构造 AbilityExecutionContext
4
4. 状态设为 Activating
5
5. 检查 Spec、Tag、Attribute、Cooldown 和并发策略
6
6. 获取本次执行需要的临时资源句柄
7
7. 进入 Running
8
8. 创建第一个 Ability Task 或执行同步步骤
9
9. 在明确边界 Commit
10
10. 等待完成、取消或失败
11
11. 统一进入 End

一个自定义 Runtime 骨架可以这样组织：

1
public sealed class AbilityRuntime
2
{
3
    private readonly List<AbilityTaskBase> tasks = new();
4
    private readonly List<IAbilityLease> leases = new();
5
    private readonly CancellationTokenSource cancellation = new();
6
    private bool isEnding;
7

8
    public AbilityRuntimeState State { get; private set; }
9
    public bool IsCommitted { get; private set; }
10
    public AbilityEndReason? EndReason { get; private set; }
11

12
    public void MarkCommitted()
13
    {
14
        if (State != AbilityRuntimeState.Running)
15
            throw new InvalidOperationException("Ability is not running.");
16

17
        IsCommitted = true;
18
    }
19

20
    public void RegisterTask(AbilityTaskBase task)
21
    {
22
        if (State != AbilityRuntimeState.Activating &&
23
            State != AbilityRuntimeState.Running)
24
        {
25
            throw new InvalidOperationException(
26
                "Ability no longer accepts new tasks.");
27
        }
28

29
        tasks.Add(task);
30
    }
31
}

AbilityTaskBase、IAbilityLease 和 AbilityRuntimeState 都是本文自定义类型。CancellationTokenSource 来自 .NET，用于传播取消信号，但它本身不等于完整的 Ability Task 生命周期。这里故意只允许 Activating 和 Running 注册 Task：一旦进入 Cancelling，清理边界就已经关闭，迟到回调不能再把新等待塞回即将结束的 Runtime。

7.3.1 为什么要保存资源句柄#

如果只在取消时写一串 RemoveTag()、EnableInput()，很难保证释放的是本次执行创建的那一份。更稳妥的方式是获取可释放句柄：

1
IAbilityLease castingTag = tagService.Acquire(
2
    source: executionId,
3
    tag: Tags.StateCasting);
4

5
IAbilityLease inputLock = inputLocks.Acquire(
6
    owner: executionId,
7
    channel: InputChannel.Ability);

释放句柄只撤销对应来源，重复释放也不产生第二次副作用。IAbilityLease 是本文自定义的资源所有权抽象。

7.4 Ability Task#

7.4.1 Task 解决的是什么#

常见 Task 可以包括：

1
WaitGameplayEventTask
2
WaitAnimationEventTask
3
WaitTargetConfirmationTask
4
WaitInputReleaseTask
5
WaitProjectileHitTask
6
WaitServerResultTask
7
DelayAbilityTask

7.4.2 Task 自己也需要状态#

一个最小 Task 生命周期可以是：

1
Created -> Active -> Completed
2
                  -> Cancelled
3
                  -> TimedOut

所有终态都必须执行同一套解绑逻辑：

1
public abstract class AbilityTaskBase : IDisposable
2
{
3
    private bool activated;
4
    private bool finished;
5

6
    protected AbilityTaskBase(AbilityExecutionId owner)
7
    {
8
        Owner = owner;
9
    }
10

11
    public AbilityExecutionId Owner { get; }
12

13
    public void Activate(CancellationToken cancellationToken)
14
    {
15
        if (finished)
16
            throw new InvalidOperationException("Task already finished.");
17

18
        if (activated)
19
            throw new InvalidOperationException("Task already activated.");
20

21
        activated = true;
22
        Register(cancellationToken);
23
    }
24

25
    protected void Complete()
26
    {
27
        Finish();
28
    }
29

30
    public void Cancel()
31
    {
32
        Finish();
33
    }
34

35
    private void Finish()
36
    {
37
        if (finished)
38
            return;
39

40
        finished = true;
41
        Unregister();
42
    }
43

44
    protected abstract void Register(CancellationToken cancellationToken);
45
    protected abstract void Unregister();
46

47
    public void Dispose()
48
    {
49
        Finish();
50
    }
51
}

这段代码只展示幂等结束骨架。实际 Task 还需要结果、失败原因、超时调度和回调到 AbilityRuntime 的安全入口。

7.4.3 协程、async/await 与 Ability Task 的差别#

三者不在同一个抽象层：

机制	主要解决
Unity Coroutine	在多个帧之间暂停和继续
C# `async/await`	组合异步操作和结果
Ability Task	谁在等待、等待什么、如何取消和解绑

因此，Ability Task 内部可以使用协程，也可以包装 C# Task，还可以只订阅事件。关键不是技术形式，而是它必须受 AbilityRuntime 所有。

例如 WaitAnimationEventTask 可以由 Unity 适配器接收动画事件，但核心 Task 只消费带执行标识的消息：

1
Animation Adapter
2
  -> GameplayEvent
3
       EventId = Event.Animation.CastPoint
4
       ExecutionId = A9001
5

6
WaitAnimationEventTask(A9001)
7
  -> 只接受 A9001 的 CastPoint
8
  -> 完成并注销

第一次施法的迟到事件带 ExecutionId = A9000，不会唤醒第二次施法 A9001。

7.5 事件关联、超时与迟到回调#

7.5.1 每个异步结果都需要关联键#

不同等待使用不同关联信息：

等待	建议关联
动画事件	ExecutionId + AnimationPhase
目标确认	ExecutionId + TargetingSessionId
输入释放	ExecutionId + InputBinding
投射物命中	ExecutionId + ProjectileId
服务器结果	RequestId + PredictionKey
Gameplay Event	ExecutionId + EventTag

注意：只有 EventTag 而没有执行标识，连续施法和并发 Ability 很容易串线。

7.5.2 超时不是异常日志，而是生命周期结果#

网络等待、目标选择和投射物等待都可能永远没有结果。Task 必须定义超时：

1
WaitServerResultTask 超时
2
  -> 不把请求当作成功
3
  -> 标记网络结果未知
4
  -> 按协议决定重试、请求快照或结束本地预测
5

6
WaitProjectileHitTask 超时
7
  -> 结束权威投射物等待
8
  -> 不应用 120 点直接伤害
9
  -> 不应用 Burning
10

11
WaitTargetConfirmationTask 超时
12
  -> 取消本次未 Commit Ability
13
  -> 释放瞄准 UI 和输入锁

超时策略属于具体 Ability 或协议配置，Task 负责准确报告结果，不擅自决定退款和伤害。

7.5.3 迟到回调必须被丢弃#

Ability Ended 后，以下回调都可能迟到：

动画状态结束；
目标选择器返回；
投射物碰撞；
服务器确认或拒绝；
延迟计时完成；
场景对象销毁通知。

安全入口至少检查：

1
Runtime 是否仍存在
2
State 是否允许推进
3
ExecutionId 是否匹配
4
Task 是否仍为 Active
5
结果是否已经消费

注意：不能依靠“我已经 StopCoroutine 了”证明所有回调都停止，因为事件总线、网络消息和投射物组件可能完全不在同一个协程里。

7.6 取消和幂等 End#

7.6.1 取消原因结构化#

建议使用稳定枚举或错误码：

1
Completed
2
Rejected
3
CancelledByInput
4
CancelledByTag
5
Interrupted
6
TargetInvalid
7
TimedOut
8
OwnerDestroyed
9
NetworkDisconnected

原因会影响：

是否播放失败、打断或正常收招表现；
是否回滚本地预测；
是否请求服务器快照；
是否保留已经 Commit 的成本与冷却；
日志和遥测如何分类。

7.6.2 推荐清理顺序#

与前文的通用执行链一致，取消时先切断异步入口，再释放状态：

1
1. State -> Cancelling
2
2. 触发 CancellationToken
3
3. 停止并注销全部 Ability Task
4
4. 移除本次执行持有的临时 Tag
5
5. 释放输入、移动、转向等资源句柄
6
6. 释放 TargetData、目标选择器和投射物等待上下文
7
7. Confirm / Reject / Correct 本次预测记录
8
8. 收束动画、VFX、UI 等预测表现
9
9. 清空实例引用
10
10. State -> Ended

已经作为独立 Active Effect 提交的状态，不在这里无条件删除：

1
保留：
2
  已 Commit 的 2 秒 Cooldown
3
  已经应用到目标的 5 秒 Burning
4

5
按策略决定：
6
  未 Commit 的预测 Mana 与预测冷却
7
  只由 Ability 临时持有的 State.Casting
8
  尚未确认的预测投射物

7.6.3 End 必须可以重复调用#

取消、超时和对象销毁可能在同一帧先后到达。End 必须幂等：

1
public void End(AbilityEndReason reason)
2
{
3
    if (State == AbilityRuntimeState.Ended || isEnding)
4
        return;
5

6
    isEnding = true;
7
    State = AbilityRuntimeState.Cancelling;
8

9
    EndReason ??= reason;
10

11
    AbilityTaskBase[] ownedTasks = tasks.ToArray();
12
    tasks.Clear();
13

14
    IAbilityLease[] ownedLeases = leases.ToArray();
15
    leases.Clear();
16

17
    cancellation.Cancel();
18

19
    foreach (AbilityTaskBase task in ownedTasks)
20
        task.Dispose();
21

22
    foreach (IAbilityLease lease in ownedLeases)
23
        lease.Dispose();
24

25
    ReleaseExecutionContext();
26
    FinishPrediction(reason);
27
    FinishPresentation(reason);
28

29
    State = AbilityRuntimeState.Ended;
30
    isEnding = false;
31
}

这里在触发 CancellationToken 前先建立 isEnding 门槛，并把 Task 与 Lease 转移到局部快照。这样同步取消回调即使重入 End()，也会立即返回；即使回调尝试注册新 Task，也会因为状态已经是 Cancelling 而被拒绝。ReleaseExecutionContext、FinishPrediction 和 FinishPresentation 是本文自定义的收束入口。生产实现还应使用 try/finally 或分阶段异常隔离，避免某个 Dispose() 抛错后阻断剩余清理。

7.6.4 Cancel 与 End 的关系#

Cancel 表达“请求中断”，End 表达“生命周期已经关闭”。

1
public void Cancel(AbilityEndReason reason)
2
{
3
    if (State == AbilityRuntimeState.Ended ||
4
        State == AbilityRuntimeState.Cancelling)
5
        return;
6

7
    State = AbilityRuntimeState.Cancelling;
8
    End(reason);
9
}

正常完成也调用同一个 End(Completed)，这样 Task、句柄和实例引用只有一套清理路径。

7.7 互斥能力、输入释放与动画事件#

7.7.1 互斥不是一个全局 `isCasting`#

较为稳定的互斥方式是定义并发策略或执行通道：

1
Channel.Action
2
Channel.Movement
3
Channel.Targeting
4
Channel.Passive

AbilitySpec 可以声明：

1
Fireball:
2
  Acquires Channel.Action
3
  Acquires Channel.Targeting
4
  Blocks abilities requiring exclusive Channel.Action

AbilityRuntime 激活时获取通道句柄，结束时按来源释放。通道只解决并发所有权，State.Stunned、Cooldown.Fireball 等规则仍由 Tag Query 处理。

7.7.2 输入按下和释放#

持续施法、蓄力和引导技能不能只监听按下。输入桥接层应把以下意图送入能力系统：

1
Pressed
2
Released
3
Cancelled

WaitInputReleaseTask 绑定 Ability 的 ExecutionId。玩家松开按键时，它只结束当前仍在等待释放的那次执行。

火球术如果采用“按下开始瞄准，释放确认目标”的交互，可以这样推进：

1
Pressed
2
  -> AbilityRuntime 进入 Running
3
  -> 创建 WaitInputReleaseTask
4
  -> 显示瞄准表现
5

6
Released
7
  -> Task 返回当前 TargetData
8
  -> 进入服务器验证与 Commit

若角色在 Released 前被眩晕，则取消 Task、隐藏瞄准表现并结束未 Commit 执行。

7.7.3 动画事件只能推进所属执行#

Unity 动画事件常见的错误接口是：

1
public void OnCastPoint()
2
{
3
    currentAbility.ReleaseProjectile();
4
}

currentAbility 很容易在连招、切换 Avatar 或并发执行时指向错误实例。更可靠的适配器应携带动画播放句柄或 ExecutionId，再发布 Gameplay Event：

1
AnimationPlaybackId = M3001
2
ExecutionId = A9001
3
Event = Event.Animation.CastPoint

WaitAnimationEventTask 同时验证三个字段。Ability 已取消时，适配器即使收到迟到动画事件，也找不到 Active Task。

动画只决定流程何时进入下一步。它不直接扣除 30 Mana，也不确认 120 点伤害。

7.8 用状态机走完一发火球术#

下面把火球术放入本章模型。先假设施法者当前 Mana 为 80，并且没有冷却和阻断 Tag。

7.8.1 正常完成#

1
输入按下
2
  -> 找到 AbilitySpec(Ability.Fireball)
3
  -> 创建 AbilityRuntime A9001
4
  -> State = Activating
5

6
激活检查
7
  -> Mana >= 30
8
  -> 不包含 State.Stunned / State.Silenced
9
  -> 不包含 Cooldown.Fireball
10
  -> 并发通道可获取
11

12
建立执行
13
  -> 获取 State.Casting 来源句柄
14
  -> 获取 Action 输入通道句柄
15
  -> State = Running
16
  -> 创建 WaitAnimationEventTask(A9001)
17

18
动画释放点
19
  -> Task 完成并注销
20
  -> 服务器验证 TargetData
21
  -> Commit：
22
       Mana -= 30
23
       添加 2 秒 Cooldown Effect
24
  -> IsCommitted = true
25
  -> 创建权威投射物
26
  -> 创建 WaitProjectileHitTask(A9001, Projectile P5001)
27

28
权威命中
29
  -> Task 完成并注销
30
  -> 对目标应用 120 点 Direct Damage
31
  -> 对目标应用 Burning：
32
       Duration = 5 秒
33
       Period = 1 秒
34
  -> End(Completed)
35

36
结束清理
37
  -> 注销残余 Task
38
  -> 移除 State.Casting
39
  -> 释放输入通道
40
  -> 清空目标和投射物等待上下文
41
  -> State = Ended

AbilityRuntime A9001 已经 Ended，但 Cooldown Effect 与 Burning Effect 按各自生命周期继续存在。

7.8.2 Commit 前被眩晕#

1
AbilityRuntime A9002
2
  -> State = Running
3
  -> 正在等待动画释放点
4
  -> IsCommitted = false
5

6
收到 State.Stunned
7
  -> Cancel(CancelledByTag)
8
  -> State = Cancelling
9
  -> 取消动画 Task
10
  -> 移除 State.Casting
11
  -> 释放输入通道
12
  -> 收束施法表现
13
  -> State = Ended

因为尚未 Commit，权威端没有扣除 30 Mana，也没有创建 2 秒冷却。客户端若显示过预测资源和冷却，应由对应预测记录撤销。

7.8.3 Commit 后投射物打空#

1
AbilityRuntime A9003
2
  -> IsCommitted = true
3
  -> Mana 已扣除 30
4
  -> 2 秒 Cooldown 已存在
5
  -> 正在等待 Projectile P5003
6

7
投射物超时
8
  -> WaitProjectileHitTask 返回 TimedOut
9
  -> 不应用 120 点直接伤害
10
  -> 不应用 Burning
11
  -> End(Completed 或 Missed，按项目原因枚举)

这条路径通常不退款，因为施法已经合法 Commit 并生成权威投射物。成本策略应由 Ability Definition 或 Commit Policy 明确，不能由 Task 自己决定。

7.8.4 客户端预测被服务器拒绝#

1
客户端 AbilityRuntime A9004
2
  -> 已进入预测 Running
3
  -> 正在等待服务器结果
4

5
Server Result
6
  -> Reject(InvalidTarget)
7

8
WaitServerResultTask
9
  -> 返回 Rejected
10
  -> Cancel(Rejected)
11
  -> 停止全部本地等待
12
  -> 释放临时 Tag 和输入锁
13
  -> 撤销预测 Mana / Cooldown
14
  -> 移除预测火球和瞄准状态
15
  -> State = Ended

服务器端没有 Commit，因此不存在权威 30 Mana 消耗和 2 秒冷却。客户端执行的是预测回滚，不是等待服务器退款。Request、Result 和 Prediction Journal 的具体协议将在后文展开。

音乐

第 7 章：Ability 生命周期与异步任务#

导入#

7.1 四个层次#

7.1.1 Ability Definition#

7.1.2 AbilitySpec#

7.1.3 AbilityRuntime#

7.1.4 Execution Context#

7.2 Ability 状态机#

7.2.1 四个核心状态#

7.2.2 Commit 是里程碑，不是生命周期终态#

7.2.3 生命周期入口需要单向#

7.3 一次激活的执行骨架#

7.3.1 为什么要保存资源句柄#

7.4 Ability Task#

7.4.1 Task 解决的是什么#

7.4.2 Task 自己也需要状态#

7.4.3 协程、async/await 与 Ability Task 的差别#

7.5 事件关联、超时与迟到回调#

7.5.1 每个异步结果都需要关联键#

7.5.2 超时不是异常日志，而是生命周期结果#

7.5.3 迟到回调必须被丢弃#

7.6 取消和幂等 End#

7.6.1 取消原因结构化#

7.6.2 推荐清理顺序#

7.6.3 End 必须可以重复调用#

7.6.4 Cancel 与 End 的关系#

7.7 互斥能力、输入释放与动画事件#

7.7.1 互斥不是一个全局 `isCasting`#

7.7.2 输入按下和释放#

7.7.3 动画事件只能推进所属执行#

7.8 用状态机走完一发火球术#

7.8.1 正常完成#

7.8.2 Commit 前被眩晕#

7.8.3 Commit 后投射物打空#

7.8.4 客户端预测被服务器拒绝#

评论区

文章目录

音乐

07-Ability生命周期与异步任务

第 7 章：Ability 生命周期与异步任务#

导入#

7.1 四个层次#

7.1.1 Ability Definition#

7.1.2 AbilitySpec#

7.1.3 AbilityRuntime#

7.1.4 Execution Context#

7.2 Ability 状态机#

7.2.1 四个核心状态#

7.2.2 Commit 是里程碑，不是生命周期终态#

7.2.3 生命周期入口需要单向#

7.3 一次激活的执行骨架#

7.3.1 为什么要保存资源句柄#

7.4 Ability Task#

7.4.1 Task 解决的是什么#

7.4.2 Task 自己也需要状态#

7.4.3 协程、async/await 与 Ability Task 的差别#

7.5 事件关联、超时与迟到回调#

7.5.1 每个异步结果都需要关联键#

7.5.2 超时不是异常日志，而是生命周期结果#

7.5.3 迟到回调必须被丢弃#

7.6 取消和幂等 End#

7.6.1 取消原因结构化#

7.6.2 推荐清理顺序#

7.6.3 End 必须可以重复调用#

7.6.4 Cancel 与 End 的关系#

7.7 互斥能力、输入释放与动画事件#

7.7.1 互斥不是一个全局 isCasting#

7.7.2 输入按下和释放#

7.7.3 动画事件只能推进所属执行#

7.8 用状态机走完一发火球术#

7.8.1 正常完成#

7.8.2 Commit 前被眩晕#

7.8.3 Commit 后投射物打空#

7.8.4 客户端预测被服务器拒绝#

评论区

文章目录

7.7.1 互斥不是一个全局 `isCasting`#