资产管理：目录结构与三级复用

特效资产出问题往往不是技术问题，而是管理问题。上千个 NS/NE 散落在 Content 根目录里，后期的每一个改动都是考古。

推荐的目录结构

Content/
  Effects/
    Environment/          # 环境：雨、雪、落叶、尘
    Combat/               # 战斗：受击、技能、爆炸
    UI/                   # 界面：升级、获得道具
    Cutscene/             # 过场专用（可能不复用）
    _Shared/              # 可复用零件：模块、通用 NE
      Modules/            # 自定义模块（NM）
      Emitters/           # 通用 NE（烟、火、光带）

一条关键原则：可复用的零件和"某个具体的特效"分开存放。具体技能的 NS 可以随便改（反正只服务一个技能），但 _Shared 里的东西被几十个 NS 引用，改动要走评审。

三级复用的分工

级别 文件 复用对象 何时做
模块 NM_（自定义模块脚本） 一个"行为"（风力、呼吸缩放） 同一逻辑出现三次以上
Emitter NE_ 一类粒子效果（烟、火） 美术调出稳定版本
System NS_ 一整段表现（一次爆炸） 需要整体复用或嵌套

不要过早抽象：出现一次的"专属爆炸"直接做成 NS，不必提取通用 Emitter。等到同样的烟出现了第三遍，再回头提取——这时候你对它的参数边界已经有了实战认识。

数据表驱动的特效管理

进阶做法：把"什么情况播什么特效"写进数据表（DataTable）而不是硬编码在逻辑里：

技能 ID 特效资产 规模参数 挂点
SK_Fireball NS_Explosion_Fire Scale=1.2 Hand_R
SK_FrostNova NS_Explosion_Frost Scale=1.0 Root

蓝图逻辑只做一件事：查表 → 拿到资产路径 → 异步加载 → 播放。这样新增技能 = 加一行表数据，策划也能做，且所有播放代码只有一份。

版本与协作

  • 用 Git / SVN 管理资产时，NS/NE 是二进制资产，锁定式协作（Lock/Checkout）优于无锁协作——两个人同时改一个 NE 会产生无法自动合并的冲突；
  • 引擎内置的模块版本管理可以处理模块升级时的兼容性（旧 NS 自动迁移到新模块版本）；
  • 命名规范的本质是可搜索性：NS_Explosion_Fire 不要写成 NsExplosionFire 或 爆炸火——大小写分隔符全文统一，搜索和维护成本最低。