5.2.1 Definition#

Definition 保存可复用的静态规则。火球术的以下内容属于 Definition：

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

在本文的 Unity 方案中，可以用 ScriptableObject 作为策划编辑和资源引用入口。下面只有 ScriptableObject、CreateAssetMenu、SerializeField 属于 Unity；AbilityId、TagQueryDefinition 和 EffectDefinition 都是本文自定义类型。

1
[CreateAssetMenu(menuName = "Combat/Abilities/Fireball")]
2
public sealed class FireballAbilityAsset : ScriptableObject
3
{
4
    [SerializeField] private string abilityId = "Ability.Fireball";
5
    [SerializeField] private int manaCost = 30;
6
    [SerializeField] private float cooldownSeconds = 2f;
7
    [SerializeField] private int directDamage = 120;
8
    [SerializeField] private float burningDurationSeconds = 5f;
9
    [SerializeField] private float burningPeriodSeconds = 1f;
10
    [SerializeField] private TagQueryDefinition blockedTags;
11
    [SerializeField] private EffectDefinition burningEffect;
12

13
    public FireballConfig BuildConfig()
14
    {
15
        return new FireballConfig(
16
            abilityId,
17
            manaCost,
18
            cooldownSeconds,
19
            directDamage,
20
            burningDurationSeconds,
21
            burningPeriodSeconds,
22
            blockedTags.BuildQuery(),
23
            burningEffect.BuildConfig());
24
    }
25
}

FireballAbilityAsset 的职责是接受 Unity 序列化和 Inspector 编辑，再生成供核心层使用的只读配置。

这些都是运行时事实。若把它们写进共享的 ScriptableObject，两个角色使用同一资产时就可能覆盖彼此状态，编辑器停止播放后还可能留下难以追踪的脏数据。

5.2.2 Runtime#

Runtime 是 Actor 级能力上下文。

在本文的 Unity 方案中，可以用一个纯 C# 的 CombatRuntime 表达这层语义：

1
public sealed class CombatRuntime
2
{
3
    public CombatRuntime(
4
        EntityId ownerId,
5
        AttributeStore attributes,
6
        TagSet tags,
7
        AbilitySpecCollection abilities,
8
        ActiveEffectCollection effects)
9
    {
10
        OwnerId = ownerId;
11
        Attributes = attributes;
12
        Tags = tags;
13
        Abilities = abilities;
14
        Effects = effects;
15
    }
16

17
    public EntityId OwnerId { get; }
18
    public AttributeStore Attributes { get; }
19
    public TagSet Tags { get; }
20
    public AbilitySpecCollection Abilities { get; }
21
    public ActiveEffectCollection Effects { get; }
22
}

这里的全部类型都是本文自定义类型，不是 Unity 组件。它们可以存在于服务器进程、客户端预测副本、离线测试或战斗回放中。

一次火球术开始前，施法者 Runtime 可能是：

1
Attributes:
2
  Mana = 80
3

4
Tags:
5
  不包含 State.Stunned
6
  不包含 Cooldown.Fireball
7

8
Abilities:
9
  拥有 Ability.Fireball 的 AbilitySpec
10

11
Effects:
12
  没有火球术冷却

Commit 后，施法者 Runtime 变成：

1
Attributes:
2
  Mana = 50
3

4
Tags:
5
  包含 Cooldown.Fireball
6

7
Effects:
8
  存在剩余约 2 秒的 Cooldown Effect

命中后，目标 Runtime 则会保存 Health 的权威变化和一个持续 5 秒、每 1 秒结算的 Burning Effect。火球 Ability 本身可以结束，但这些 Runtime 状态继续存在。

5.2.3 Simulation#

Runtime 保存事实，Simulation 推进事实。二者需要分开，否则 CombatRuntime 很快会膨胀成包含每一种技能分支的上帝对象。

Simulation 可以包含以下服务：

1
AbilityActivationService
2
  -> 查询 AbilitySpec、Tag、Attribute 和 Cooldown
3

4
AbilityCommitService
5
  -> 以统一边界提交 Cost 和 Cooldown
6

7
EffectApplicationService
8
  -> 创建 EffectInstance，修改 Attribute，贡献 Tag
9

10
EffectScheduler
11
  -> 推进 Duration 与 Periodic Effect
12

13
AbilityExecutionService
14
  -> 创建 AbilityRuntime，驱动状态迁移和取消
15

16
TargetValidationService
17
  -> 验证目标数据并生成可执行上下文

通用原则：Simulation 应依赖显式输入，而不是在规则执行到一半时偷偷读取全局单例、场景时间或随机的 MonoBehaviour。

例如 Effect 的推进可以接收统一时钟：

1
public interface ICombatClock
2
{
3
    double Now { get; }
4
}
5

6
public sealed class EffectScheduler
7
{
8
    private readonly ICombatClock clock;
9

10
    public EffectScheduler(ICombatClock clock)
11
    {
12
        this.clock = clock;
13
    }
14

15
    public void Advance(CombatRuntime target)
16
    {
17
        target.Effects.AdvanceTo(clock.Now);
18
    }
19
}

ICombatClock 和 EffectScheduler 是本文自定义类型。测试可以提供一个手动推进的时钟，服务器可以提供权威 Tick 时钟，客户端可以提供用于表现和预测的本地时钟。规则层不必直接依赖 Time.time，也不必为每个 Effect 启动独立协程。

5.2.4 Transport#

在本文的 Unity 方案中，核心层只接受协议数据：

1
public readonly record struct AbilityRequest(
2
    string RequestId,
3
    ulong SpecId,
4
    string AbilityId,
5
    ulong PredictionKey,
6
    uint ClientTick,
7
    uint ClientSequence,
8
    TargetData TargetData);
9

10
public readonly record struct AbilityResult(
11
    string RequestId,
12
    ulong PredictionKey,
13
    AbilityResultKind Kind,
14
    AbilityResultStage Stage,
15
    AbilityResultCode Code,
16
    ulong ResultVersion,
17
    ulong AuthorityRevision,
18
    bool Committed,
19
    AuthoritativeState AuthoritativeState);

这些都是本文自定义 DTO，不是 Unity Netcode for GameObjects、Mirror、Photon 或其他网络库的内置消息。

Transport 只能传递和关联结果，不能因为收到客户端的 TargetData 就直接对目标扣除 120 Health。最终结算仍然属于权威 Simulation。

5.2.5 Presentation#

Presentation 面向 Unity 场景和玩家体验。它适合使用 MonoBehaviour、Animator、粒子、音频、相机和 UI，也可以根据本地玩家、其他玩家和旁观者采用不同表现策略。

它消费的应当是语义事件：

1
Cue.Fireball.CastStarted
2
Cue.Fireball.Launched
3
Cue.Fireball.Impact
4
Cue.Burning.Started
5
Cue.Burning.Tick
6
Cue.Burning.Ended

而不是把规则写进表现回调

动画事件可以推进 Ability，但它本身不是伤害权威。粒子没有播放成功，也不能撤销服务器已经确认的 Burning。

5.3.1 Definition 不引用运行时对象#

Definition 可以引用其他静态定义，例如火球术引用 Cost、Cooldown、Damage 和 Burning 的 Effect Definition，但不能引用某个角色的 CombatRuntime、某次 AbilityRuntime 或场景中的目标对象。

可以把它理解为：

1
允许：
2
  Fireball Definition
3
    -> Mana Cost Effect Definition
4
    -> Cooldown Effect Definition
5
    -> Direct Damage Effect Definition
6
    -> Burning Effect Definition
7

8
禁止：
9
  Fireball Definition
10
    -> 当前玩家 Runtime
11
    -> 当前锁定目标 GameObject
12
    -> 上一次施法的 PredictionKey

Definition 的共享性依赖它不可被一次执行污染。需要根据等级、装备或运行时参数调整数值时，应创建执行期的配置快照或 Effect Spec，而不是修改共享资产。

5.3.2 Runtime 保存状态，不选择表现#

Runtime 可以保存 Effect.Burning 是否存在、下一次周期结算时间和来源句柄，但不应该保存“使用哪个火焰粒子预制体”这种表现决策。

同一份 Burning 状态可能有多种呈现：

• 本地玩家看到完整粒子、音效和屏幕边缘提示；
• 远端玩家只看到简化粒子；
• Dedicated Server 完全不创建表现对象；
• 自动化测试只断言 Tag、周期和到期时间。

把表现资源放进 Runtime，会迫使服务器和测试环境依赖 Unity 场景资源。

5.3.3 Simulation 不直接发送网络消息#

Simulation 的输出应是结构化结果或领域事件，例如：

1
AbilityAccepted
2
AbilityRejected
3
AttributeChanged
4
EffectApplied
5
EffectRemoved
6
CueRequested

Transport 再决定这些结果发给谁、是否可靠发送、如何批量和序列化。这样规则测试只需要断言“服务器接受后 Mana 从 80 变为 50，并产生 2 秒冷却”，不需要等待一个真实 RPC。

5.3.4 Transport 不重写规则#

客户端适配器和服务器适配器最容易产生一份“为了少调用几层”的平行规则：

1
客户端 RPC 入口检查一套 Mana 与 Tag
2
Simulation 又检查另一套 Mana 与 Tag

本地预检查可以存在，但权威请求必须进入同一个 AbilityActivationService。Transport 只负责验证消息结构、连接上下文和基础协议合法性，战斗条件仍由 Simulation 判断。

5.3.5 Presentation 不拥有最终战斗事实#

UI 可以显示预测 Mana，投射物表现可以预测飞行，动画可以先于服务器确认播放，但它们都必须接受后续确认或撤销。

Presentation 不应该提供这类入口：

1
public void OnImpactVisualPlayed()
2
{
3
    target.Health -= 120;
4
}

它应该接收已经关联来源和生命周期的 Cue：

1
public void HandleCue(GameplayCue cue)
2
{
3
    cuePlayer.Play(cue);
4
}

GameplayCue 和 cuePlayer 是本文自定义的表现协议与适配对象，不是 Unity 内置 API。

5.4.1 哪些能力可以留在 Unity 适配层#

下面这些职责适合由 Unity 侧适配：

• 输入系统回调；
• Animator 状态和动画事件；
• 场景射线、碰撞查询和挂点位置采样；
• GameObject 与网络 EntityId 的映射；
• 粒子、音效、镜头和 UI；
• Update 或 Fixed Tick 对核心时钟的驱动；
• ScriptableObject 到只读配置的构建。

但适配层输出的场景结果仍需进入规则边界。例如场景射线得到一个候选目标，不代表它已经通过服务器的距离、阵营和可受击验证。

5.6.1 最小可行版本#

单机或服务器先行的最小版本可以只包含：

用火球术验收时，应至少能证明：

1. Mana 少于 30 时拒绝激活；
2. 激活成功后 Mana 扣除 30；
3. Cooldown.Fireball 持续 2 秒并自动撤销；
4. 命中时应用 120 点直接伤害；
5. Burning 持续 5 秒，每 1 秒触发一次周期结算；
6. Ability 结束后 Burning 仍由目标 Runtime 继续维护；
7. 取消时 Task、临时 Tag 和事件订阅都被清理。

这个版本还不需要 Prediction Journal、状态快照或真实 RPC。它先证明规则语义和生命周期成立。

5.6.2 多人版本#

多人版本在最小实现上增加：

客户端和服务器可以运行相同的规则语义，但只有服务器能把结果写成最终事实；客户端的本地变化必须被标记为预测。