定位#

本文不以“把 UE 的类名搬到 Unity”为目标，也不试图实现一个完整的 GAS 替代品。真正要解决的是多人战斗中反复出现的边界问题：

• 谁拥有 Mana、Health 和冷却等状态；
• 谁决定一次技能是否成功、是否命中；
• 一次性伤害、持续 Buff、周期结算和标签如何拥有明确生命周期；
• 技能等待动画、目标确认或命中事件时如何取消；
• 客户端已经播放表现而服务器拒绝时，如何校正；
• 如何在不启动 Unity 场景的情况下测试战斗规则。

阅读时应始终先问“这段逻辑解决哪类问题、状态归谁、在哪一端运行”，再去看它在某个引擎里的类名。

前置知识#

建议先具备：

1. C# 基础，以及 Unity MonoBehaviour、ScriptableObject 和生命周期概念；
2. 客户端、服务器、RPC、状态同步和延迟的基本认识；
3. 熟悉 Health、Mana、Buff、Debuff、冷却和技能打断；
4. 能读懂简化的 C# 与时序图代码。

火球术统一示例#

部分章节只会使用其中一部分参数，但不会改写这些约定。Burning 的每次伤害数值如果没有特别声明，只讨论它的生命周期和结算节奏，不补充一个新的伤害数值。

章节导航#

概念标记规则#

为了避免把 UE、Unity 和通用设计混在一起，正文使用以下标记：

• 在 UE GAS 中：描述 Unreal Engine 官方 GAS 语义或对象职责。这里的 AbilitySystemComponent、GameplayAbility、GameplayEffect 等是 UE 术语。
• 在本文的 Unity 方案中：描述本文提出的 Unity 侧架构。AbilityDefinition、AbilitySpec、AbilityRuntime、AttributeStore、PredictionJournal 等都是本文自定义类型，不是 Unity 内置 API。
• 通用原则：不依赖具体引擎或网络库的设计判断，例如“最终伤害由权威端决定”“持续状态需要明确到期和清理责任”。
• 示例代码：用于说明数据流或边界的简化代码，不代表可以直接复制进项目。代码中的省略号、伪接口和未展示的序列化细节都需要项目自行补齐。

如果一个代码片段同时出现 Unity 内置类型和本文自定义类型，会在片段前明确说明。例如 ScriptableObject 是 Unity 类型，而 AbilityDefinition 是本文定义的资产类型；MonoBehaviour 反例只用于展示职责耦合，不代表推荐的最终实现。