Skip to main content
摘要:本文聚焦「Unity 资产命名规范与强制检查工具」,梳理核心概念、关键方法与落地实践。
文档目标: 建立统一的资产“语言”,解决项目后期“找不到资源”的噩梦。 核心逻辑: [前缀]_[模块/类别]_[名称]_[变体/后缀]

1. 🕵️ 真实开发场景演示 (Real-World Workflows)

规范只是枯燥的列表,我们来看看在实际开发中,一整套资源是如何命名的。

场景 A:制作一个敌人 “Goblin Warrior” (哥布林战士)

目标:在 Project 窗口搜索 “Goblin”,所有相关文件整齐排列,不混杂其他东西。

场景 B:搭建一个 “Dungeon” (地牢) 场景

目标:模块化拼装。区分“地砖”、“墙壁”和“装饰物”。

场景 C:UI 按钮状态 (图片资源)

目标:区分图片的用途,防止把 3D 贴图用到 UI 上。

场景 D:预制体深度命名 (Prefab Specifics)

目标:让成百上千个 Prefab 在文件夹里自动归类,而不是乱成一团。

1. UI 预制体 (PUI)

  • 规则: P_UI_[Layer]_[Feature]_[Sub]
  • P_UI_Panel_Settings (设置面板 - 全屏)
  • P_UI_Popup_Confirm (确认弹窗 - 模态)
  • P_UI_HUD_PlayerInfo (战斗界面 - 玩家信息)
  • P_UI_Item_InventorySlot (列表项 - 背包格子,会被大量克隆的小组件)

2. 技能/子弹预制体 (PSkill / PBullet)

  • 规则: P_Skill_[Owner]_[Element]_[Name]
  • P_Skill_Hero_Fire_Fireball (主角火球)
  • P_Skill_Hero_Ice_FrostNova (主角冰环)
  • P_Bullet_Arrow_Wood (普通木箭)
  • P_Bullet_Magic_Missile (魔法飞弹)
  • FX_Hit_Fire_Small (命中特效 - 属于 PFX 类别)

3. 角色预制体 (PChar)

  • P_Hero_Archer (主角 - 弓箭手)
  • P_Enemy_Slime_Green (敌人 - 绿史莱姆)
  • P_Boss_Dragon_Red (Boss - 红龙)
  • P_NPC_Merchant (NPC - 商人)

2. ➖ 下划线的艺术:何时连接,何时切断?

下划线 _ 在计算机世界里通常代表 “层级 (Hierarchy)”“分割 (Split)“。乱用下划线会导致名字支离破碎。

2.1 黄金法则:Snake_Pascal (蛇形大驼峰)

我们推荐一种混合命名法:用下划线分割层级,用大驼峰连接单词。
  • ✅ 正确: T_DarkKnight_D
    • 解析: [T] 是前缀,[DarkKnight] 是主体,[D] 是后缀。结构清晰 (A_B_C)。
  • ❌ 错误: T_Dark_Knight_D
    • 解析: 到底是 Dark_Knight 是主体?还是 Dark 是主体,Knight 是变体?
    • 后果: 当你写脚本解析文件名时,string.Split('_') 会得到 4 段,逻辑变复杂。

2.2 必须用下划线的场景 (Must Use)

  1. 前缀之后: P_, T_, M_。这是为了让排序时,所有同类资源聚在一起。
  2. 后缀之前: _D, _N, _01, _Hover。这是为了标记变体。
  3. 核心分类与名称之间: UI_Btn_Close。这里 Btn 是分类,Close 是名称。

2.3 禁止用下划线的场景 (Must Avoid)

  1. 复合名词内部:
    • Fire_Ball
    • FireBall
    • 理由: 它们是一个整体概念,不要切断。
  2. 形容词与名词之间:
    • Big_Boss
    • BigBoss
  3. 系列编号之前 (除非是后缀):
    • Level_01_Boss
    • Level01_Boss (如果 Level01 是一个整体概念)

2.4 为什么这么较真? (Tooling Impact)

很多工具依赖下划线来工作:
  • Texture Packer (UI 打包): 默认使用下划线识别动画序列。Run_01, Run_02 会被打包成 Run 动画。如果你写成 Hero_Run_01,它可能认为这是 Hero 组下的 Run 动画。如果你写成 Hero_Fast_Run_01,它就晕了。
  • Substance Painter: 导出贴图时,通常自动加 _BaseColor。保持主体部分干净 (DarkKnight) 可以确保导出文件名整洁。

3. 🔠 大小写的语义学:为什么要这么写?

大小写规则不仅仅是好不好看,它是代码的表情符号。理解了语义,你就不需要死记硬背。

3.1 PascalCase (大驼峰) —— 🎩 尊贵的类型

  • 规则: 每个单词首字母大写。 PlayerController, GetDamage
  • 语义: 代表公开的、重要的、定义性质的东西。
  • 应用:
    • class (类名): Enemy
    • function (方法名): Attack()
    • public 变量: public float Health;
    • 资产文件名: P_GoblinWarrior (除了前缀,主体部分用 PascalCase)

3.2 camelCase (小驼峰) —— 🐁 内部的数据

  • 规则: 首字母小写,后续单词首字母大写。 moveSpeed, enemyTarget
  • 语义: 代表私有的、内部的、实例性质的数据。感觉比较“轻”。
  • 应用:
    • 局部变量: float distance = ...
    • 参数: void Attack(float damageAmount)

3.3 _camelCase (下划线小驼峰) —— 🔒 私有的字段

  • 规则: 下划线开头 + 小驼峰。 _currentHealth, _playerTransform
  • 语义: “私人财产,请勿触碰”
  • 应用:
    • private 成员变量: private float _timer;
    • 好处: 在代码里看到 _ 开头的变量,你就知道它是全局的私有变量,而不是函数里的临时变量。

3.4 SCREAMING_SNAKE_CASE (尖叫蛇) —— ⚠️ 警告/常量

  • 规则: 全大写,下划线分隔。 MAX_HP, DEFAULT_SPEED
  • 语义: “我在尖叫!我是常量!不要试图修改我!”
  • 应用:
    • const 常量: const int MAX_ENEMIES = 100;
    • static readonly 静态只读配置。

3.5 总结对照表


4. 🆘 非母语者的命名生存指南 (Survival Guide for Non-Native Speakers)

对于中文团队,强制英文命名最大的障碍是词汇量和拼写错误。为了避免 T_GongJi_Tx (拼音缩写) 这种可怕的东西出现,请遵守以下“生存法则”。

4.1 📚 受控词表 (Controlled Vocabulary)

不要去翻牛津词典! 游戏开发中用到的高频词只有这 100 个。请全员打印并贴在显示器旁边,强制只用这些词

🅰️ 通用动作 (Actions)

🧱 物体与材质 (Materials)

🧛 角色与职业 (Roles)

📊 RPG 核心属性 (Stats & Attributes)

参考来源: Path of Exile, Dota 2, Genshin Impact

🔮 特殊机制与状态 (Mechanics)

🖥️ UI 与界面 (Interface)

4.2 🛠️ 拼写检查工具

  1. PowerToys Run (Windows):Alt + Space 呼出搜索框,输入中文直接查英文。
  2. 编辑器插件: 使用 VS Code 或 Rider 的拼写检查插件 (SpellChecker)。如果代码里的变量名下面有波浪线,说明你拼错了,赶紧改,不要带到资源名里。

4.3 🇨🇳 拼音特赦区 (The Pinyin Exception)

什么时候可以用拼音? 只有当这个概念在英文中完全没有对应词,或者翻译过去会丢失核心神韵时。
  • ✅ 允许: Wuxia (武侠), Jianghu (江湖), Qigong (气功), GuanYu (关羽 - 专有名词)。
  • ❌ 禁止: Shouqiang (Pistol), Daguai (Farming), Boss_1_Sihou (Roar)。

4.4 📏 缩写规范

为了避免 Pos 是 Position 还是 Possess 的歧义,只允许使用通用缩写
  • Pos = Position
  • Rot = Rotation
  • Dir = Direction
  • Tex = Texture
  • Mat = Material
  • Mgr = Manager
  • Ctrl = Controller
  • Cfg = Config

5. 📜 基础规范详情 (The Standards)

5.1 基础规则

  1. 语言: 严禁中文命名。使用英文 (PascalCase 或 snake_case)。
  2. 分隔符: 使用下划线 _ 分隔前缀和主体。
  3. 文件夹约束: 特定资产必须放在特定文件夹下(如 UI 图片必须在 Assets/Art/UI)。

5.2 🔤 前缀对照表 (Prefix Table)

5.3 🔡 后缀对照表 (Suffix Table - 纹理专用)


6. 💡 常见困惑解答 (FAQ)

Q1: 为什么要区分 T_ (Texture) 和 UI_ (Sprite)?

  • A: 它们的导入设置完全不同!
    • T_ 通常是 POT (2 的次幂),开启 Mipmaps,使用 DXT/ASTC 压缩。
    • UI_ 通常是 NPOT (任意尺寸),关闭 Mipmaps,开启 Sprite Packer,关闭压缩或用高质量压缩。
    • 命名区分后,可以写脚本自动根据前缀设置 Import Settings,省去人工检查的麻烦。

Q2: 什么时候用 _01, _02,什么时候用 _A, _B?

  • 数字 (_01): 用于同类枚举
    • 例子: SM_Rock_01, SM_Rock_02, SM_Rock_03 (都是石头,随便用哪个都行)。
  • 字母 (_A): 用于风格/状态变体
    • 例子: UI_Icon_Skill_A (方形版), UI_Icon_Skill_B (圆形版)。

Q3: 脚本 (Script) 需要前缀吗?

  • A: 不需要 S_Cs_ 前缀。
  • 脚本类名直接作为文件名:PlayerController.cs, GameManager.cs
  • 原因: 脚本在代码中被引用时,前缀会破坏代码的可读性 (S_Player.Move() 很难看)。

7. 👮‍♂️ 强制检查脚本 (The Enforcer Script)

将下方的脚本放入项目的 Assets/Editor 文件夹中。