Unity资源规范

Unity资源规范

命名规范

一个资源该如何命名？

  • 优先使用英文命名、其次中文，不建议使用汉语拼音。
  • 如果定好了命名语言，尽可能保证同一文件夹的文件都统一，别混用。
ShiZi //不建议（必须人工解读，但没有声调和上下文，难以正确解读。石子、狮子、柿子？）
Persimmon //正确（放入翻译软件中即可得为：柿子）
柿子 //正确（一眼看懂，但部分底层软件存在兼容问题，但不会影响功能使用）
  • 如果基于英语或拼音，那应采用“帕斯卡命名法”（每个单词首字母大写）。
  • 确保利用驼峰分割名称后，可从翻译软件中得到对应中文。
//正确（大写字母能起到分隔符的作用，添加空格后可以从翻译软件反向查到对应中文）
TourGuide
TourGuideHat
  • 不要使用纯简单的字母、数字、预设名称等无意义命名，命名必须能解释自身内容。
//错误示范（看了让人不知道相关资源是干啥的）
a
1
白1
微信图片_20251224112419_4_2
Circle_004 1
  • 当文件夹用于分类用途时，应将其采用英语且复数形式命名，并优先使用Unity的预设名称（参考存放规范）。
//正确（这不仅按规范来了，而且这是Unity标准的存放纹理的文件夹，会影响Unity自动链接纹理的方式）
Textures

存放规范

多个资源该如何存放？

  • 存放基本方法：

    存放的基本方法参考了程序中的作用域思想，一个物体的作用域是指“该物体可以被那些其他物体使用，又或者说可以使用哪些其他物体”。资源存放以文件夹为容器，每个资源的作用域就受限于其所存储的文件夹及其同目录的其他文件夹。这样可以实现封装的思想（不需要关注子文件夹的内容，子文件夹由父文件夹的资源进行调度）以此文件夹才有了实现的意义与标准。

  • 存放基本原则：

    1. 兼容特殊文件夹，以Unity的官方文件夹设计为原型。
    2. 实现模块化，便于快速以功能为单位进行文件管理。
    3. 同类型放一起，以便对资源进行各种批量预处理操作。

    一句话总结：“在基本结构下，先按模块放，再按类型放”。

下面是基于上述“方法”和“原则”的指导下，对Unity文件夹结构的具体实现。其中前缀有加减号表示是文件夹，加减代表其是否展开；此外所有特殊文件夹都使用英文名称，示例的自定义文件夹则采用中文命名。

项目基本结构

这是对原则第一点的实现，定制了对Assets文件夹的标准骨架。

+ Assets
  + Artworks：存放美术资源等游戏原始素材。
    - Audios：音频文件
    - Videos：视频文件
    - UI：用户界面用到的图片
    - Effects：特效相关
    - Models：模型相关
  - Plugins：存放第三方插件，会影响编译顺序。（官方）
  - Resources：Resources功能所用，会影响资源剥离。（官方）
  - Samples：存放包示例。（官方）
  - Scenes：存放打包场景。（官方）
  - Settings：存放全局项目设置，例如渲染管线、默认字体、默认导入设置等。
  - Sources：存放实现的功能模块，包括源代码、相关Unity资源、做好的预制体等。

  • Artworks 和 Sources：

    在接入 git 的环境下，美术师主要在 Artworks 文件夹工作，程序员主要在 Sources 文件夹工作，否则所有文件夹都由程序员管理。多人协作时，程序员有义务监督规范项目结构，以便实现功能需求、提高开发效率等。

  • Effects 和 Models：

    这两个文件夹都会存储一些模型材质纹理资源，但两者的目的不同，Effects 由特效师管理，程序员理论上只管使用（通常程序员不会做特效）。Models 则是建模师仅提供资源，由程序员负责管理组装，该文件的内容，程序员能处理也需要处理，它通常不能像特效那样拿来就用。

    Effects 是特效师做好的成品，Models 是建模师提供的原始素材。

Artworks文件夹中已经开始体现 “先按模块放，再按类型放” 的思维模式了。Audios、Videos、UI都是功能明确独立的资源，他们都被分类存放。“纹理”、“材质”、“动画”等资源则没有出现在 Artworks 文件夹，因为他们都强绑定“模型”文件，所以按模块化思想，被细分到了Effects和Models文件夹。

模块文件夹命名

模块在此是指：“一组为实现相同功能的资源”，故模块文件夹就是存放这些模块资源的文件夹。

这是对原则第二点的命名相关实现。模块文件夹属于用户自定义文件夹，所以命名只要能满足“命名规范”即可，具体内容可以自定。

+ Effects
  + 拖尾
    - 拖尾1
    - 拖尾2
  - 爆炸
  - 烟雾

上述 Effects 中的所有文件夹都是自定义的模块文件夹，可以看到没有特殊的地方，都是直接按其内容很直白的命名。

类型文件夹命名

这是对原则第三点的实现。当同目录的同类资源超过两个时就要考虑分类存放，分类时需采用特殊文件夹的形式，常用的特殊文件夹如下：

  • Materials：存放材质球资源（官方）
  • Textures：存放纹理资源（官方）
  • Animations：存放动画相关资源
  • Meshes：存放网格资源
  • Prefabs：存放预制体资源
  • Scripts：存放脚本资源

如果上述文件夹不能满足需求，你完全可以按需定制，基本规则就是以相关资源的类型英文单词为基准，首字母大写加复数的方式命名文件夹即可，例如：Texts（文本文件）。

注意：Meshes不等于模型，因为模型本身可以包含很多内容，例如动画。所以具体要按模型的作用进一步细分，如果只是为了提供动画，应将模型放到Animations，如果是提供显示的网格，才该放到Meshes中。

处理模块依赖

这是对原则第二点的进一步实现。既然采用了模块化，就必然要处理模块化中的依赖问题。具体处理方式有两种：

  1. 若同一文件夹中的资源都存在一些公共依赖的资源，那可将这些被依赖资源按对应类型存放于这些文件的共同父文件夹中。
  2. 若同一文件夹中纯在多个资源，他们之间的依赖资源也各有差异，那可将被依赖资源也作为模块的一种，放入同级文件夹。

示例：

+ Models
  + 角色舞蹈
    动作1.fbx
    动作2.fbx
    动作3.fbx
  + 玩家角色
    + Animations
      跳跃.fbx
      奔跑.fbx
    - 角色1
    + 角色2 
      + Animations：
        角色2普攻.fbx
        角色2大招.fbx
      + Mateirals
        角色2.mat
      + Textures
        角色2.png
      角色2.fbx
  - 非玩家角色
  - 武器
  - 载具
  • Models/玩家角色/Animations：该文件夹为特殊分类文件夹，意味着他不是独立模块。其作用域为同目录所有其他文件夹，这意味着“角色1”、“角色2”会引用其中内容。
  • Models/玩家角色/角色2/Animations：该文件夹也是特殊分类文件夹，其作用域也为当前目录。但当前目录是“角色2”的专用模块文件夹，所以说明该资源仅被“角色2”使用。
  • Models/角色舞蹈：该文件夹非特殊文件夹，而是作为独立模块存放，这意味着他可能被部分同目录其他模块引用，例如“玩家角色”、“非玩家角色”可以使用该资源，但“武器”、“载具”不需要。不过显而易见的的是这里可以将“玩家角色”、“非玩家角色”进一步模块化为“角色”文件夹，这样“角色舞蹈”就可以按第一种依赖处理方式实现了。

凸显模块作用

模块都是为功能而产生，是功能的原始素材，那么最终一定有一个功能的成品。为了突出这一成品的作用，应将其存放到模块文件夹的根目录。

例如：

+ Models
  + 武器
    - Materials
    - Textures
    武器.fbx
  + 载具
    - Materials
    - Textures
    + Meshes
      轮胎.fbx
      车架.fbx
    载具.prefab
+ Effects
  + 爆炸
    - Textures
    + Effects
      爆炸核心.vfx
      爆炸核心2.vfx
      爆炸气体.prefab
    爆炸.prefab
    爆炸2.prefab
  • Models/武器/武器.fbx：武器文件夹主要提供一个完整的模型显示效果，因此武器.fbx可以作为模块成品放在根目录。
  • Models/武器/载具.prefab：虽然是模型文件夹，但提供预制体也没问题，例如你可以借此拼装模型，添加动画，只要确实是成品即可。
  • Effects/爆炸/爆炸.vfx、Effects/爆炸/爆炸.vfx：其他类型的文件也都可以，甚至你可以放多个样式在根目录，将你期望给别人用的东西放在外面。

Demo 文件夹

该规范实质属于存放规范的一部分，但仅“特效师”和“程序员”需要阅读。

实现模块的测试和示例部分

功能不是一开发出来就任务结束的，开发出来后势必存在后期维护和教授他人使用的阶段，为了实现这一过程，应尽可能的为模块添加 Demo 文件夹。

Demo 文件夹中配有若干场景（可能也包含这些场景专属的依赖资源），这些场景可以直观呈现模块成品的效果，是一个运行就可以使用的应用案例。如果一个模块添加了Demo文件夹，那么就要在模块内新建一个Sources文件夹收纳原本的文件。例如：

+ Scenes
  博物馆.unity
+ Sources
  + TourGuide
    + Demo
      TourGuideTest.unity
      TourGuideTest.cs
    + Sources
      + Models
        - Materials
        - Textures
        导游.fbx 
      + Animations
        待机.fbx
        走路.fbx
        标准人物运动.controller
      - Scripts
      TourGuide.prefab

例如上面的示例中，程序员就提供了其负责的导游模块的示例场景。这有以下好处：

  1. 其本人无需运行完整的应用场景（博物馆.unity），就可以直接借用 TourGuideTest.unity 来快速迭代开发新功能。
  2. 如果程序发生异常，或其他模块发生变动，只用测试 TourGuideTest.unity 就可以确定问题是否与导游模块相关。
  3. 其他需要使用导游模块的程序员，不需要专门咨询原作者，直接查看示例场景就可以直到如何使用。

实际示例

下面是一个多人协作场景下的文件夹结构示例

示例文件夹结构

  • Assets/Artworks/Models/手写板：建模师提供基本的画板模型。
  • Assets/Artworks/Effects/笔迹拖尾：特效师提供了基本的绘制时的画笔拖尾特效。
  • Assets/Sources/DrawingBoard：程序员最终将两者组合实现完整画板功能。
  • Assets/Sources/GameController：可能的额外程序员，用于整合功能模块，实现游戏主逻辑。

基于模块化的思想管理文件夹带来如下好处：

  1. 每个人都可以有专门的工作文件夹，干活互不冲突，效率很高。
  2. 当涉及模块依赖时，由于模块成品被突出放置，立即就能拿到需要的资源。
  3. 因为功能相关文件都放一起且没有多余，移植到其他项目仅需简单移动文件夹即可。

基于分类的思想管理带来如下好处：

  1. 查找资源时可以快速定位到目标位置，而不需要筛选其他文件。
  2. 大部分美术资产都需要预处理（如压缩，mipmap等资源优化），由于同类都放一起，批处理非常方便
  3. 不同功能的同类资源，预处理参数一般是不同的（例如背景音和按钮音效，需采用不同的内存加载策略），故先模块再类型，可以自动筛除掉用途不同的同类资源。
posted @ 2026-01-27 17:34  BDFFZI  阅读(117)  评论(0)    收藏  举报