特效规范与评审流程

特效一旦多到几十上百个，"规范"就不再是形式主义，而是团队协作的地基。这份规范在多个项目中验证过，直接可用。

命名规范

资产 格式 示例
System NS_<类别>_<名字> NS_Combat_Fireball、NS_Env_Rain
Emitter NE_<类别>_<名字> NE_Combat_Spark、NE_Env_Mist
模块 NM_<功能> NM_WindForce、NM_FadeByDistance
材质 M_<类别>_<名字> M_VFX_SmokeSoft、M_VFX_SparkAdd

类别用固定的几个：Combat（战斗）、Env（环境）、UI、Cutscene（过场）、Char（角色）。可读性优先于缩写：NS_Combat_Fireball 比 NS_CB_FB 好，新人一眼看懂。

评审流程（三道门）

阶段 参与者 检查项
立项门 美术 + 策划 这个特效是否有通用参数化价值？要不要做成可复用零件
实现门 美术 + 程序 是否用了共享 Emitter？参数暴露是否合理？命名是否合规
上线门 程序 + 测试 开销达标？打包后在目标平台验证过？数据表已登记

第三道门是最常被跳过的——"编辑器里跑得好好的"不等于"打包后也好好的"（资产引用、平台差异、真机性能，三个坑都在这里等着）。

文档：一个"特效登记表"

用一个表格（或 DataTable 的可视化）登记所有在线特效：

NS 资产 用途 播放场景 预估开销 负责人 平台档位
NS_Combat_Fireball 火球术 战斗 0.4ms 美术 A 全平台
NS_Env_Rain 环境雨 关卡 3 1.2ms 美术 B PC / 高配移动

这张表的价值在于后期优化时不用满项目找资产，也方便新成员入职时快速建立全局图景。

规范落地的小技巧

  • 把命名规范写成编辑器启动时的检查脚本（用 Editor Utility 批量扫描不合规资产）；
  • _Shared 目录设置权限或走 Code Review，防止误改公共零件；
  • 每次版本提交时让工具自动更新"特效登记表"的开销列（把实测数据写回表里）。