URL
status
type
date
slug
summary
tag
category
password
icon
之前看到了Unreal官方发布的资产命名规范，但Unity官方好像没有，所以就参阅了几篇相关文章，再加上了游戏项目的一些其他规范，最后整理成此文以适用于Unity的团队协作。
为什么需要在项目一开始就考虑良好的结构？对于初学者来说，它的纪律性很好，你做的越多，它就会变得越自然，最终会节省你的时间。在类似的精心设计的基础上构建多个项目也可以更容易地在项目之间进行交换。必须尽早设计的最令人信服的原因是，如果原型已经用良好的系统设计构建，那么将其滚动到生产项目中是非常容易的。
当软件变得更大时，很难维持这一事实。这就是诀窍，如果你不早点维护它并保持它有条理，你以后会遇到困难，并且会发现自己浪费时间整理混乱而不是专注于功能。在早期阶段确定项目的文件结构，并为各类资产建立通用的命名规范。这样便于和团队成员寻找文件，防止出现冲突或混淆。
资产命名规范
时刻记住这个命名规范，只要遵守它，大部分情况下都可以让命名规范。下面是详细的解释。
所有资源都应该有一个
BaseAssetName(基本资源名)。所谓基本资源名表明该资源在逻辑关系上属于那种资源，任何属于该逻辑组的资源都应该遵守同样的命名规范基本资源名应该使用简短而便于识别的词汇，例如，如果你有一个角色名字叫做Bob，那么所有和Bob相关的资源的
BaseAssetName都应该叫做BobVarient(扩展名)用来保证资源的唯一性，同样，扩展名也应该是简短而容易理解的短词，以说明该资源在所属的资源逻辑组中的子集。例如，如果Bob有多套皮肤，那么这些皮肤资源都应该使用Bob作为基本资源名同时包含扩展名，例如'Evil'类型的皮肤资源，名字应该是Bob_Evil，而Retro类型的皮肤应该是用Bob_Retro一般来说，如果仅仅是为了保证资源的唯一性，
Varient可以使用从01开始的两位数字来表示。例如，如果你要制作一堆环境中使用的石头资源，那么他们应该命名为Rock_01, Rock_02, Rock_03等等。除非特殊需要，不要让数字超过三位数，如果你真的需要超过100个的资源序列，那么你应该考虑使用多个基础资源名基于你所制作的资源扩展属性，你可以把多个扩展名串联起来。例如，如果你在制作一套地板所使用的资源，那么你的资源除了使用
Flooring作为基本名，扩展名可以使用多个，例如Flooring_Marble_01, Flooring_Maple_01, Flooring_Tile_Squares_01。Assets目录中的所有资源文件名（场景、脚本、预设、模型、网格、纹理、材质、精灵、着色器、音频剪辑、视频剪辑）均采用 大驼峰式命名法 ，即每一个单词的首字母都大写。且使用能够描述其功能或意义的英文单词或词组。
此表未列出所有可能性，因为随着新功能出现，新资产类型也会出现。如果你要使用的资产类型未列出，可以参考以下表格为其指定命名规范。
通用类型
资源类型 | 前缀 | 后缀 | 备注 |
Level / Map | ㅤ | ㅤ | |
Level (Persistent) | ㅤ | _P | _P表示是一个大的容器Level，在这个Level里可以异步加载其他小Level |
Level (Audio) | ㅤ | _Audio | ㅤ |
Level (Lighting) | ㅤ | _Lighting | ㅤ |
Level (Geometry) | ㅤ | _Geo | ㅤ |
Level (Gameplay) | ㅤ | _Gameplay | ㅤ |
Material | M_ | ㅤ | ㅤ |
Static Mesh | S_ or SM_ | ㅤ | 选一个，建议使用 S_. |
Skinned Mesh | SK_ | ㅤ | ㅤ |
Texture | T_ | _? | 参照纹理 |
Particle System | PS_ | ㅤ | ㅤ |
Canvas | UI_ | ㅤ | ㅤ |
动作
资源类型 | 前缀 | 后缀 | 备注 |
Animator Controller | AC_ | ㅤ | ㅤ |
Animator Override Controller | AOC_ | ㅤ | ㅤ |
Animation | AM_ | ㅤ | ㅤ |
Skinned Mesh | SK_ | ㅤ | ㅤ |
材质
资源类型 | 前缀 | 后缀 | 备注 |
Material | M_ | ㅤ | ㅤ |
Shader | S_/SD_ | ㅤ | 建议SD_ |
Physical Materials | PM_ | ㅤ | ㅤ |
纹理
资源类型 | 前缀 | 后缀 | 备注 |
Texture | T_ | ㅤ | ㅤ |
Texture (Diffuse/Albedo/Base Color) | T_ | _D | ㅤ |
Texture (Normal) | T_ | _N | ㅤ |
Texture (Roughness) | T_ | _R | ㅤ |
Texture (Alpha/Opacity) | T_ | _A | ㅤ |
Texture (Ambient Occlusion) | T_ | _O or _AO | 选一个，建议使用 _O. |
Texture (Bump) | T_ | _B | ㅤ |
Texture (Emissive) | T_ | _E | ㅤ |
Texture (Mask) | T_ | _M | ㅤ |
Texture (Specular) | T_ | _S | ㅤ |
Texture (Packed) | T_ | _* | ㅤ |
Texture Cube | TC_ | ㅤ | ㅤ |
Media Texture | MT_ | ㅤ | ㅤ |
Render Texture | RT_ | ㅤ | ㅤ |
Cube Render Texture | RTC_ | ㅤ | ㅤ |
纹理合并
把多张纹理存于一个纹理文件中是很常见的方法，比如通常可以把自发光(Emissive), 粗糙度(Roughness), 环境光(Ambient Occlusion)以RGB通道的形式保存在纹理中，然后在文件的后缀中，注明这些信息，例如
_EGO一般来说，在纹理的Diffuse信息中附带Alpha/Opacity信息是很常见的，这时在_D后缀中可以加入A也可以不用加
不推荐同时把RGBA四个通道的信息保存在一张纹理中，这是由于带有Alpha通道的纹理要比不带的占用更多的资源，除非Alpha信息是以蒙版(Mask)的形式保存在Diffuse/Albedo通道中。
杂项
资源类型 | 前缀 | 后缀 | 备注 |
Playables Behavior | PB_ | ㅤ | ㅤ |
Playables Assets | PA_ | ㅤ | ㅤ |
2D
资源类型 | 前缀 | 后缀 | 备注 |
Sprite | SPR_/SP_ | ㅤ | ㅤ |
Sprite Atlas Group | SPRG_/SPG_ | ㅤ | ㅤ |
Tile Map | TM_ | ㅤ | ㅤ |
物理
资源类型 | 前缀 | 后缀 | 备注 |
Physical Material | PM_ | ㅤ | ㅤ |
Destructible Mesh | DM_ | ㅤ | ㅤ |
声音
资源类型 | 前缀 | 后缀 | 备注 |
Audio Mixer | Mix_ | ㅤ | ㅤ |
Sound Wave | A_ | ㅤ | ㅤ |
界面
资源类型 | 前缀 | 后缀 | 备注 |
Font | Font_ | ㅤ | ㅤ |
Effects
Asset Type | Prefix | Suffix | Notes |
Particle System | PS_ | ㅤ | ㅤ |
Material (Post Process) | PP_ | ㅤ | ㅤ |
目录结构规范
对资源目录的规范管理和资源文件同等重要，都应该像法律一样被严格遵守。不规范的目录结构会导致严重的混乱。Unity为开发者提供完全的自由。这就是为什么它经常会变得混乱。并且由于没有适当的项目文件夹结构，我们无法谈论组织。下面的1和2是两种完全不同的分类方式，所以需要参照项目的具体内容，来选择合适的目录结构规范。
目录结构1
有多种不同管理Unity资源目录的方法，在本套规范中，我们尽量利用了Unity的Project视图的过滤和搜索功能来查找资源，而不是按照资源类型来划分目录结构。
如果你正确遵守了前面使用前缀的资源命名规范，那么就没有必要按照资源类型创建类似于Meshes, Textures, 和 Materials这样的目录结构，因为你可以在过滤器中通过前缀来找到特定类型的资源
以上蓝色标注的项目为特殊文件夹。Unity保留了一些特殊的文件名称用来做一些特殊的用途，如果你的文件夹命名了这类的文件名，引擎内部就会对它进行一些特殊的处理，这些特殊目录对脚本的编译也会有影响。
文件夹说明
Assets 主目录
项目资源的主目录，unity项目中的所有资源都必须在此目录下才能在project面板中出现。
Editor 编辑器目录
放在此目录的脚本将被视为编辑器脚本，编辑器脚本为编辑器提供一些扩展或定制功能，但是无法在运行时使用。editor文件夹可以放置在assets目录中的任意子目录中。
Gizmos 标识目录
gizmos允许你将一些图标添加到场景中，作为一些辅助标示，比如可以标示出一些正常情况下看不见的线或点，使用gizmos.drawicon方法可以在场景中绘制图标用来做一些特殊的标记，当然前提是你得将图标放到gizmos文件夹中，这样drawicon方法才能找到它。需要注意的是，gizmos目录需要全局唯一，和editor不一样，它得固定放到跟目录下，就是说它的上一级只能是assets。
Plugins 插件目录
插件文件夹，用来放置一些三方的库插件，比如ngui，或者是一些dll库，比如json、dotween等三方库，也可以放置你自己封装的dll文件。同gizmos一样，全局唯一，必须在根目录下。
Resources 资源目录
资源文件夹，主要的美术素材、音频、视频、模型、特效、动画等资源存放地址。同editor一样，可以在主目录下任意子目录中存在。该目录下的内容在打包时都会被打到发布包中。
工程版本资源直接使用Resource加载方式，发布阶段根据项目需求统一切换资源加载方案。
特点：
- 只读，即不能动态修改。所以想要动态更新的资源不要放在这里。
- 会将文件夹内的资源打包集成到.asset文件里面。
- 主线程加载。
子目录：
- Audios 音频文件
- Animations 动画资源（片段资源放在Resources/Animations/xxx/anim中）控制器要和anim文件同级
- Fonts 字体
- Materials 材质（贴图和材质存放在同级目录下）
- Models 美术模型（模型和贴图材质文件夹存放在同级目录下）
- Prefabs 预制体
- SFXs 特效资源
- Sprites 精灵资源
- Videos 视频文件
- 具体业务文件夹 具体业务需要的特殊资源存放的文件夹（例如Scriptobject类型的数据资源文件、骨骼资源文件等）
Scenes 场景目录
存放场景文件，不包括插件的案例场景文件（第三方插件的案例文件可以先放在原位置）
除初始运行场景外,其他场景都要放在各自的分类文件夹中
子目录：
- Lights
- Cameras
- AR_Manager
- World
- GUI
- Scene_Manager
- _Dynamic
Scripts 脚本目录
存放C#、Shader脚本，代码内容，注意Unity3D的C#代码规范同微软.NET FRAMEWORK规范相同详情可以参照文档。
子目录：
- Commons：通用类
- Tools：工具类
- Shaders：自己写的shader
- 具体业务文件夹：根据架构创建业务文件夹
Standard Assets 标准资源目录
标准资源文件夹，存放unity提供的标准资源文件的文件夹。
StreamingAssets 流文件目录
用于存放一些流文件，比如音视频文件、二进制文件、assetbundle文件。全局唯一，存放在根目录下。和Resources文件的区别就是Resources文件夹中的内容在打包时会被压缩和加密。而StreamingAsset文件夹中的内容则会原封不动的打入包中，因此StreamingAssets主要用来存放存放打包的AB资源，然后用户安装包之后把这些AB资源是放到手机内。特点：
- 只读，可以放一些压缩的AB资源。
- 只能用过WWW类(新版本都已采用UnityWebRequest来取代WWW)来读取。
Unity 中的大多数资产在构建时都会合并到项目中。但是，有时将文件放入目标机器上的普通文件系统以使它们可以通过路径名访问是有用的。这方面的一个例子是在 iOS 设备上部署电影文件；原始电影文件必须可从文件系统中的某个位置获得，才能由
PlayMovie 函数播放。任何放置在 Unity 项目中名为 StreamingAssets （区分大小写）的文件夹中的文件都将被逐字复制到目标计算机上的特定文件夹中。您可以使用 Application.streamingAssetsPath 属性检索文件夹 。始终最好使用
Application.streamingAssetsPath 获取 StreamingAssets 文件夹的位置，因为它将始终指向运行应用程序的平台上的正确位置。此文件夹的位置因平台而异。请注意，这些是区分大小写的：
- 在台式计算机（Mac OS 或 Windows 计算机）上，可以使用以下代码获取文件的位置：
path = Application.dataPath + "/StreamingAssets";
- 在 iOS 上，使用：
path = Application.dataPath + "/Raw";
- 在 Android 上，使用：
path = "jar:file://" + Application.dataPath + "!/assets/";
SandBox 沙盒目录
对于您不完全确定的任何实验，请使用“SandBox”目录。当您与其他人一起进行项目时，请创建您的个人沙盒子目录，例如：
SandBox/San目录结构2
一级目录，以资源文件使用的目的进行分类
Assets根目录下的文件夹分类如下
文件夹说明（01-10为自定义文件夹，最后4个为默认目录，即系统可识别文件夹，保证名字丝毫不差）：
【01.Scenes】：存放所有场景（Scene）文件，统一管理，方便快速寻找并打开场景。
【02.UI】：存放与游戏界面（UI）相关的资源文件，比如按钮，图标，输入框，列表等。
【03.Environment】：存放与环境相关的资源文件，比如背景，建筑物，地形，天空，树木，水体等。
【04.Characters】：存放与人物相关的资源文件，比如玩家控制的角色，敌人，怪兽，NPC，动物等。
【05.Effects】：存放与特效相关的资源文件，比如粒子系统，摄像头渲染特效，动作特效，技能特效，画面特效等。
【06.Input】：存放与玩家输入相关的资源文件，比如PC输入，触屏输入，游戏手柄输入，自定义输入等。
【07.Network】：存放与网络通讯相关的资源文件，比如服务器连接，网络缓存，即时通讯等。
【08.Database】：存放与数据库操作相关的资源文件，比如本地存储，网络存储等。
【09.Others】：存放暂时不知道如何归类的资源文件。
【10.Test】:存放与游戏测试相关的资源文件，在游戏发布前删除该文件夹。
【Editor】：插件目录，该目录在编译项目时，会优先编译，方便项目中代码调用。
【Plugins】：该目录下的代码可调用Unity Editor 的API，存放扩展编辑器的代码。编译时不会被打包到游戏包中。
【Resources】：项目中默认的资源路径，会直接打包到游戏包中，并且可在脚本中加载该目录下的资源。
二级目录，根据资源文件的文件类型分类
文件夹说明：
【Animations】：动画 相关的资源文件。
【Animators】：动画控制器 相关的资源文件。
【Audios】：音频 相关的资源文件。
【Materials】：材质 相关的资源文件。
【Models】：模型 相关的资源文件。
【Prefabs】：预制体 相关的资源文件。
【Sprites】：精灵 相关的资源文件。
【Shaders】：着色器 相关的资源文件。
【Scripts】：脚本 相关的资源文件。
【Textures】：纹理 相关的资源文件。
注明：如果该二级目录不存在某个类型的资源文件，可以省略其文件夹，如【02.UI】目录下：
三级目录，直接存放相关类型的资源文件
如下【Animators】目录下存放所有的动画文件：
美术资源规范
一、单位，比例统一
在建模型前先设置好单位，在同一场景中会用到的模型的单位设置必须一样，模型与模型之间的比例要正确，和程序的导入单位一致，即便到程序需要缩放也可以统一调整缩放比例。统一单位为米。
二、模型规范
⒈所有角色模型最好站立在原点。没有特定要求下，必须以物体对象中心为轴心。
⒉面数的控制。移动设备每个网格模型控制在300-1500个多边形将会达到比较好的效果。 而对于桌面平台，理论范围1500-4000。如果游戏中任意时刻内屏幕上出现了大量的角色，那么就应该降低每个角色的面数。比如，半条命2对于每个角色使用2500-5000个三角面。
正常单个物体控制在1000个面以下，整个屏幕应控制在7500个面以下。所有物体不超过20000个三角面。
⒊整理模型文件，仔细检查模型文件，尽量做到最大优化，看不到的地方不需要的面要删除，合并断开的顶点，移除孤立的顶点，注意模型的命名规范。模型给绑定之前必须做一次重置变换。
⒋可以复制的物体尽量复制。如果一个1000面的物体，烘焙好之后复制出去100个，那么他所消耗的资源基本和一个物体消耗的资源一样多。
三、材质贴图规范
⒈我们目前使用的Unity3D软件作为仿真开发平台，该软件对模型的材质有一些特殊的要求，在我们使用的3dsMax中不是所有材质都被Unity3D软件所支持，只有standard(标准材质)和Multi/Sub-Object(多维/子物体材质)被Unity3D软件所支持。注：Multi/Sub-Object(多维/子物体材质)要注意里面的子材质必须为standard(标准材质)才能被支持。
⒉Unity3D目前只支持Bitmap贴图类型，其它所有贴图类型均不支持。只支持DiffuseColor（漫反射）同self-Illumination(自发光，用来导出lightmap)贴图通道。 Self-Illumination（不透明）贴图通道在烘焙lightmap后，需要将此贴图通道channel设置为烘焙后的新channel，同时将生成的lightmap指向到self-Illumination。
四、贴图文件格式和尺寸
原始贴图不带通道的jpg，带通道的为32位tga或者 png，尺寸最大别超过2048，贴图文件尺寸须为2的N次方 （8、16、32、64、128、256、512、1024）最大贴图尺寸不能超过1024x1024，特殊情况下尺寸可在这些范围内做调整。
五、贴图材质应用规则
⒈贴图不能为中文命名，不能有重名；
⒉材质球命名与物体名称一致，材质球的父子层级的命名必须一致；
⒊同种贴图必须使用一个材质球；
⒋除需要用双面材质表现的物体之外，其他物体不能使用双面材质；
⒌材质的ID和物体的ID号必须一致；
⒍若使用completemap烘焙，烘焙完毕后会自动产生一个shell材质，必须将shell材质变为standard标准材质，并且通道要一致，否则不能正确导出贴图；
⒎带Alpha通道的贴图存储为tga或者png格式，在命名是必须加_al以区分。
⒏模型需要通过通道处理时需要制作带有通道的纹理，在制作树的通道纹理是，最好将透明部分改为树的主色，这样在渲染是可以使有效边缘部分的颜色正确，通道纹理在程序渲染时占用的资源币同尺寸的普通纹理要多。通道纹理命名时应以_al结尾。
六、模型烘焙及导出
⒈模型的烘焙方式有两种：一种是LightMap烘焙贴方式，这种烘焙贴图渲染出来的贴图只带有阴影信息，不包含基本纹理。具体应用于制作纹理较清晰的模型文件（如地形），原理是将模型的基本纹理贴图和LightMap阴影贴图两者进行叠加。优点是最终模型纹理比较楚，而且可以使用重复纹理贴图，节约纹理资源；烘焙后的模型可以直接导出FBX文件，不用修改贴图通道。缺点是LightingMap贴图不带有高光信息；
⒉另一种是CompleteMap烘焙方式，这种烘焙贴图方式的优点是渲染出来的贴图本身就带有基本纹理和光影信息，但缺点是没有细节纹理，且在近处时纹理比较模糊。
⒊烘焙贴图设置。
在进行completemap烘焙方式设置时应注意：贴图通道和物体uv坐标通道必须为1通道，烘焙贴图文件存储为tga格式，背景要改为与贴图近似的颜色；
lightingmap烘焙设置时，和completemap设置有些不同，贴图通道和物体uv坐标通道必须为3通道，烘焙时灯光的阴影方式为adv.raytraced 高级光线跟踪阴影，背景色要改为白色，可以避免黑边的情况。主要物件的贴图uv必须手动展开。
七、模型绑定及动画
1.骨骼必须为IK、CAT、BIP三类，unity不认虚拟体动画，单个物体骨骼数量不超过60个。
2.动画帧率、帧数的控制，一般情况下为每秒10帧，一个动画尽量控制在1秒内完成。
3.角色蒙皮、动作调节规范详见---（动画规范流程表）。
4.导出动画，分开2个文件，导出没有动作的模型、骨骼，模型需要带有蒙皮信息。之后调节好做动画后导出的就是只有骨骼的fbx文件。
八、模型导出
1.将烘焙材质改为标准材质球，通道为1，自发光100%；
2.所以物体名、材质球名、贴图名保持一致；
3.合并顶点，清除场景，删除没有用的一切物件；
4.清材质球，删除多余的材质球（不重要的贴图要缩小）；
5.按要求导出fbx（检查看是否要打组导出），导出fbx后，再重新导入max中查看一遍fbx的动画是否正确；
6.根据验收表格对照文件是否正确；
九、文件备份提交标准
⒈最终确认后的max文件分 角色模型、场景模型、道具模型带贴图存放到服务器相应的" 项目名/model/char“ ”项目名/model/scene“ ”项目名/model/prop"文件夹里面。动画文件对应的存放至anim 文件夹中。
⒉导出给程序obj、fbx等格式文件统一存放至export文件夹下的子文件夹anim、model、prop
十、项目命名要求
⒈项目进入策划时，各部门统一为项目命好名称，服务器建立项目名称文件夹，制作人员本机制作时建立对应名称的项目文件夹。
⒉角色模型命名：项目名_角色名字，max文件中模型对象如果需要分开各部位时，应在此命名的基础上_部位，如角色头部命名为：项目名_角色名_head ，以此类推。对应的材质球、贴图都将命名一致。
⒊场景、道具命名：项目名_场景名称，max文件中对应的物体为项目名_场景名物体名，同类的比较多的情况下，命名为：[项目名_场景名_物体名_序号],同类型的物体以数字类推方式命名。材质球、贴图对应物体名字。同类物体只需要给同一个材质球，同一贴图即可。
⒋带通道的贴图：要加_al后缀
⒌特效贴图以特效名称命名，贴图加入_vfx后缀。
几条注意事项
- 避免分支 assets： 任何 assets 都应该永远只有一个版本。如果您必须对预制件、场景或网格进行分支，必须非常清楚哪个是正确版本的过程。“错误”的分支应该有一个时髦的名称，例如，使用双下划线前缀：
__MainScene_Backup。
- 每个团队成员都应该有一个项目的第二个副本进行测试： 如果您正在使用版本控制。更改后，应更新和测试第二个副本，即干净副本。任何人都不应该对他们的干净副本进行任何更改。这对于捕获丢失的资产特别有用。
- 以 XML 中而不是在 Scenes 保存 levels：
无需重新设置每个场景。
它使加载速度更快（如果大多数对象在场景之间共享）。
它使合并场景变得更加容易。
它使跨级别跟踪数据变得更加容易。
- 尽量保持简短： 取一小段代码，然后思考：“一个出色的解决方案应该是什么样子？”。尽量保持你的 classes 用较少的行。一个小 class 应该少于 100 行。一个中级 class，不到 400 行。并且 main class 不到 1000 行。如果你传递这个数字，你可能正在创建一个上帝类，我们真的想避免这种情况。
- 不要在文件和文件夹名称中使用空格，因为我们 Unity3D 命令行工具无法自动处理带有空格的路径。
- 不要在根目录中存储任何资产文件。尽可能使用子目录。
- 除非您确实需要，否则不要在根目录中创建任何其他目录。
- 命名要一致。如果您决定对目录名称使用驼峰式大小写，对资产使用小写字母，请遵守该约定。
- 使用单独的“Third_Party”文件夹，来存储从 Asset Store 导入的资产。它们通常有自己的结构，不应更改。
- 使用命名的空游戏对象作为场景文件夹。 仔细组织您的场景，以便轻松找到对象。所有空对象应位于 0,0,0 并具有默认旋转和缩放。
- 当你在运行时实例化一个对象时，确保把它放在_Dynamic 中，不要污染你的根层次结构，否则你会发现它很难导航。
- 将维护预制件和文件夹（空游戏对象）放在 0 0 0 处。 如果变换不是专门用于定位对象，则它应该位于原点。这样，在本地和世界空间中遇到问题的风险就会降低，并且代码通常更简单。
- 将角色和站立对象的枢轴放在底部，而不是中心。 这使得将角色和物体精确地放在地板上变得容易。它还使得使用 3D 变得更容易，就好像它是 2D 的游戏逻辑、人工智能，甚至在适当的时候使用物理一样。
- 使所有网格面向同一方向（正或负 z 轴）。 这适用于网格，例如角色和其他具有朝向概念的对象。如果所有东西都具有相同的朝向，那么许多算法都会被简化。
- 从一开始就把 Scale 做好。 制作艺术品，以便它们都可以以 1 的比例因子导入，并且它们的变换可以按 1,1,1 比例缩放。使用参考对象（Unity cube）使比例比较容易。选择适合您的游戏/项目的世界与 Unity 单位的比率。
- 使游戏/项目可在每个场景中都可以运行。 这大大减少了测试时间。要使所有场景都可运行，您需要做两件事：首先，提供一种方法来模拟以前加载的场景所需的任何数据（如果它不可用）。其次，使用以下惯用语生成必须在场景加载之间持续存在的对象：
参考文章：
- 作者:Cloud
- 链接:https://cloud09.xyz/article/d4f8ce87-32a2-49e1-8aa7-dc862d1ae48a
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。