[自己在使用的一套規範]

自己用的規範, 雖然打印成PDF也還行. 但是版本總是會混亂的, 不如直接丟在Blog上更新好了

持續更新中

[文档头]

版本 :0.0.3

此处用于快速查找基本要求

三维默认单位: CM(厘米)
若无指定, 默认图像格式 : Png 8/16bpc | Tga 8bpc

[文件名称与结构的规范]

原则

遵守规范

如果你工作的项目或你的团队已经有一套自己的规范，那么请尊重它。
如果现有规范和本套规范发生冲突，请继续遵守原规范。

好的项目规范应该是不断进步的，当你发现有好的更改可以适合所有用户时，你应该建议去更改现有规范

“0.1 对规范优劣的争论是没有意义的，有规范你就该去遵守。”
Rebecca Murphey

“0.2 不管团队中有多少人，工程中所有的数据结构、资源、代码风格应该统一，如同是同一个人的作品”

把资源从一个工程迁移到另一个工程不应该产生新的学习成本
所有资源应该符合项目规范，消除不必要的歧义和不确定性
遵守规范可以促进对于项目的生产和维护效率
因为团队成员不用去考虑规范问题，只需要去遵守
本套规范根据诸多优秀经验编写，遵守它意味着可以少走很多弯路。

“0.3 好哥们也得讲原则”

如果你发现同事不遵守规范，你该去纠正他

当你在团队中工作时，或者在社区提问时(例如Unreal Slackers)

你会发现如果大家都遵守同一套规范会容易的多，没有人愿意在面对一堆乱糟糟的蓝图或者莫名其妙的代码时帮你解决问题

具体规范看这里

如果你要帮助的人使用另一套不同但很健全的规范，你应该去适应它，如果他们没有遵守任何规范，那么带他们来这儿

0. 资源命名约定

对于资源的命名的规范应该像法律一样被遵守。
一个项目如果有好的命名规范，那么在资源管理、查找、解析、维护时，都会有极大的便利性。
大多数资源的命名都应该有前缀，前缀一般是资源类型的缩写，然后使用下划线和资源名链接。

1.默认命名原则

请一律使用英文半角字符作为命名字符
请使用英文单词直接示意,保持可读性.不得混合使用中文拼音
- 最佳应当长期准备一个字典软件
不使用 [ \ / * # ^ ? { } ” < > | ~ ` @ $ % & . , ;] 等字符
由于目标引擎为Unreal引擎, 规则应当优先遵循目标引擎的结构

2.树状结构的原则

层级结构需要确立树关系,同类型应当保证同级组织
根据资产类型进行科叶分类

1. 规则

1.1 基本命名规则

Prefix_BaseAssetName_Variant_Suffix

时刻记住这个命名规范Prefix_BaseAssetName_Variant_Suffix，只要遵守它，大部分情况下都可以让命名规范。
- 下面是详细的解释。
Prefix(前缀) 和 Suffix(后缀)由资源类型确定，请参照下面的 [1.2 资源类型表 ]
所有资源都应该有一个BaseAssetName(基本资源名)。
- 所谓基本资源名表明该资源在逻辑关系上属于那种资源，任何属于该逻辑组的资源都应该遵守同样的命名规范
基本资源名应该使用简短而便于识别的词汇，例如，如果你有一个角色名字叫做Bob，那么所有和Bob相关的资源的BaseAssetName都应该叫做Bob

Varient(扩展名)用来保证资源的唯一性，同样，扩展名也应该是简短而容易理解的短词，以说明该资源在所属的资源逻辑组中的子集。

例如，如果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。

1.1a 范例

1.1e1 Bob (角色)

资源类型	资源名
Skeletal Mesh	SK_Bob
Material	Mat_Bob
Texture (Diffuse/Albedo)	Tex_Bob_D
Texture (Normal)	Tex_Bob_N
Texture (Evil Diffuse)	Tex_Bob_Evil_D

1.1e2 Rocks (道具)

资源类型	资源名
Static Mesh (01)	SM_Rock_01
Static Mesh (02)	SM_Rock_02
Static Mesh (03)	SM_Rock_03
Material	M_Rock
Material Instance (Snow)	MI_Rock_Snow

1.2 资源类型表

当给一个资源命名的时候，请参照以下表格来决定在资本资源名前后所使用的前缀和后缀

我们不可避免会出现有同种类型的不同缩写, 但是请确保在同一个区域内, 它们总是一致的

1.2.1 通用类型

资源类型	前缀	后缀	备注
Level / Map 关卡			所有地图应该放在Maps目录下
Level (Persistent) 主干		_P
Level (Audio) 做音频时		_Audio
Level (Lighting) 打照明时		_Lighting
Level (Geometry) 做Block时		_Geo
Level (Gameplay) 做玩法时		_Gameplay
Blueprint 蓝图脚本	BP_
Material 材质	M_ or Mat_	_?	如有特殊用途,应当附加用途后缀
Static Mesh 静态网格体	S_ or SM_		官方用SM_
Skeletal Mesh 骨架网格体	SK_
Texture 贴图	T_ or Tex_	_?	如有色彩空间,应附加色彩空间后缀
Particle System 粒子系统	PS_
Widget Blueprint UI组件蓝图	WBP_ or WB_		建议使用 WBP_.

1.2.2 动作

资源类型	前缀	备注
Aim Offset 注视偏移	AO_ or Aim_
Aim Offset 1D	AO_ or Aim_
Animation Blueprint 动画蓝图	ABP_ or AnimBP_
Animation Composite 动画合成	AC_ or AnimComp_
Animation Montage 动画剪辑	AM_ or AnimMT_
Animation Sequence 动画序列	A_ or AS_ or AnimSeq_	选一个，建议使用 A_.
Blend Space 混合空间	BS_
Blend Space 1D	BS_
Level Sequence 关卡序列	LS_
Morph Target 变形目标	MT_
Paper Flipbook 翻页动画	PFB_
Rig 绑定	Rig_
Skeletal Mesh 骨架网格体	SK_
Skeleton 骨骼	SKEL_

1.2.3 AI

资源类型	前缀	后缀	备注
AI Controller AI控制器	AIC_
Behavior Tree 行为树	BT_
Blackboard 黑板	BB_
Decorator 装饰器	BTDecorator_
Service 伺服监听的	BTService_
Task 任务	BTTask_

1.2.4 蓝图

资源类型	前缀	备注
Blueprint 蓝图	BP_
Blueprint Function Library 蓝图函数库	BPFL_
Blueprint Interface 蓝图接口	BPI_
Blueprint Macro Library 蓝图宏	BPML_	可能的话尽量不要使用蓝图宏
Enumeration 枚举	E or Enum	没有下划线
Structure 结构体	F or S	没有下划线
Widget Blueprint UI部件蓝图	WBP_ or WB_	选一个，建议使用 WBP_.

1.2.5 材质

资源类型	前缀	备注
Material 材质	M_ or Mat_
Material (Post Process) 后处理材质	PP_ or PostMat_
Material Function 材质函数	MF_ or MatFunc_
Material Instance 材质实例	MI_ or MatIns_
Material Parameter Collection 材质参数表	MPC_
Subsurface Profile 次表面配置	SP_ or SSP_	选一个，建议使用 SP_.
Physical Materials 物理材质	PM_ or PhyMat_

1.2.6 纹理

资源类型	前缀	后缀	备注
Texture 贴图	T_ or Tex_
Texture (Diffuse/Albedo/Base Color) 基色	T_ or Tex_	_D or _Diffuse or _Albedo or _Diff
Texture (Normal) 法线	T_ or Tex_	_N or _Nor or _Normal or _Norm
Texture (Roughness) 粗糙	T_ or Tex_	_R or _Rough
Texture (Alpha/Opacity) 透明	T_ or Tex_	_A or _OP
Texture (Ambient Occlusion) 环境遮蔽	T_ or Tex_	_O or _AO	选一个，建议使用 _O.
Texture (Bump) 凹凸	T_ or Tex_	_B or _Bump
Texture (Emissive) 自发光	T_ or Tex_	_E or _EM
Texture (Mask) 蒙版	T_ or Tex_	_M or _Mask
Texture (Specular) 反射强度	T_ or Tex_	_S or _Spec
Texture (Packed) 打包的	T_ or Tex_	_*	参见下面的纹理打包备注.
Texture Cube 立方体贴图	TC_ or TexCube_
Media Texture 媒体流送	MT_
Render Target 渲染目标	RT_ or RTT_		选一个，建议使用 RT_.
Cube Render Target 立方体渲染目标	RTC_
Texture Light Profile 灯光贴图配置	TLP_ or TxLitPf_

1.2.6.1 纹理合并

把多张纹理存于一个纹理文件中是很常见的方法，比如通常可以把自发光(Emissive), 粗糙度(Roughness), 环境光(Ambient Occlusion)以RGB通道的形式保存在纹理中，然后在文件的后缀中，注明这些信息，例如_EGO

一般来说，在纹理的Diffuse信息中附带Alpha/Opacity信息是很常见的，这时在_D后缀中可以加入A也可以不用加

不推荐同时把RGBA四个通道的信息保存在一张纹理中
这是由于带有Alpha通道的纹理要比不带的占用更多的资源，除非Alpha信息是以蒙版(Mask/ 单位掩码) 的形式保存在Diffuse/Albedo通道中。
- 此处涉及到图像压缩的处理, 可以参照微软的 Texture Block Compression 对详细信息进行了解

资源类型	前缀	后缀	备注
Texture (Packed)	T_ or Tex_	_ARM	A:Albedo,R:Roughness,M:Metallic (RGB)

1.2.7 杂项

资源类型	前缀	后缀	备注
Animated Vector Field 动画向量场	VFA_
Camera Anim 相机动画	CA_ or CamAnim_
Color Curve 色彩曲线	Curve_ or Crv_	_Color
Curve Table 曲线表	Curve_ or Crv_	_Table
Data Asset 数据资产	?_		前缀取决于何种类型资源
Data Table 数据表	DT_
Float Curve 浮点曲线	Curve_ or Crv_	_Float
Foliage Type 植被类型	FT_
Force Feedback Effect 力反馈效果	FFE_
Landscape Grass Type 地形草地	LG_
Landscape Layer 地形层	LL_
Matinee Data 过场数据	Matinee_
Media Player 媒体播放器	MP_
Object Library 对象库	OL_
Redirector 重定向器	RD_
Sprite Sheet 精灵粒子表	SS_
Static Vector Field 静态向量场	VF_
Touch Interface Setup 按步骤触摸交互	TI_
Vector Curve 向量曲线	Curve_ or Crv_	_Vector

1.2.8 2D

资源类型	前缀	后缀	备注
Paper Flipbook 翻页动画	PFB_
Sprite 精灵粒子	SPR_
Sprite Atlas Group 切片精灵粒子组	SPRG_
Tile Map 排布映射	TM_ or TMap_
Tile Set 排布集	TS_

1.2.9 物理

资源类型	前缀	后缀	备注
Physical Material 物理材质	PM_ or PhyMat_
Physical Asset 物理资产	PHYS_ or Phys_
Destructible Mesh 破碎网格	DM_

1.2.10 声音

资源类型	前缀	后缀	备注
Dialogue Voice	DV_
Dialogue Wave	DW_
Media Sound Wave	MSW_
Reverb Effect	Reverb_
Sound Attenuation	ATT_
Sound Class			没有前缀和后缀，这些资源应该放在SoundClasses目录中
Sound Concurrency		_SC	在SoundClass之后命名
Sound Cue	A_	_Cue
Sound Mix	Mix_
Sound Wave	A_

1.2.11 界面

资源类型	前缀	备注
Font	Font_
Slate Brush 地编刷	Brush_
Slate Widget Style	Style_
Widget Blueprint	WBP_ or WB_	选一个，建议使用 WBP_.

1.2.12 特效 Effects

Asset Type	Prefix	Suffix	Notes
Particle System 粒子系统	PS_
Material (Post Process) 后处理材质	PP_

2. 目录结构

对资源目录的规范管理和资源文件同等重要，都应该像法律一样被严格遵守。不规范的目录结构会导致严重的混乱。

有多种不同管理UE4资源目录的方法，在本套规范中，我们尽量利用了UE4的资源浏览器的过滤和搜索功能来查找资源，而不是按照资源类型来划分目录结构。

如果你正确遵守了前面使用前缀的资源命名规范，那么就没有必要按照资源类型创建类似于Meshes, Textures, 和 Materials这样的目录结构，因为你可以在过滤器中通过前缀来找到特定类型的资源 , 按照此规范主要是为了避免产生资源之间的污染

2e1 目录结构示例

下方示例皆时文件夹, 并非资产文件, 请区分它们

|-- Content
    |-- Project : 主项目(顶级目录)
        |-- Environment : 环境地编资产库
        |   |-- Foliage : 植被类型
        |   |-- Props : 道具类型
        |-- Characters : 角色资产库
        |   |-- NpcA : 角色A
        |   |   |-- Animations : 角色A的动作库
        |	|	|	|-- Cinematic : 特定镜头的修正动作
        |   |   |-- Audio : 角色A的音频库
        |   |   |-- Clothes : 角色A的布料结算相关
        |	|	|	|-- Cinematic : 特定镜头的修正特效
        |   |   |-- Hair : 角色A的头发特效相关
        |   |   |-- FX : 角色A的其他特效相关
        |   |-- Common : 公用资源
        |   |   |-- Animations : 动作库
        |   |   |-- Audio : 音频库
        |   |-- NpcB : 角色B
        |-- Core : 程序相关的逻辑库
        |   |-- Characters : 角色
        |   |-- Engine : 引擎相关的
        |   |-- GameModes : 游戏模式
        |   |-- Attachments : 附件相关的逻辑(如武器)
        |-- Effects : 公用的特效
        |	|-- Specific : 特殊用途的
        |	|	|-- Cinematic : 特定镜头的特殊修正特效
        |   |-- Electrical : 雷
        |   |-- Fire : 火
        |	|	|-- Cinematic : 特定镜头的特殊修正特效
        |   |-- Weather : 天气
        |	|	|-- OpenVDB : 使用VDB格式的天气视效
        |-- Maps : 关卡/地图
        |   |-- Level01 : 关卡01
        |   |	|-- Branch01 : 关卡01-非全局分支版本01(如需保留)
        |   |	|-- Branch02 : 关卡01-非全局分支版本02(如需保留)
        |   |-- Level02 : 关卡02
        |-- Sequencer : 动画序列
        |	|-- Cut001 : 序列镜头001
        |	|-- Cut002 : 序列镜头002
        |	|	|-- Branch01 : 序列镜头002-非全局分支版本01
        |	|	|-- Branch02 : 序列镜头002-非全局分支版本01
        |	|-- Cut003 : 序列镜头003
        |-- MaterialLibrary : 公用基础材质库
        |   |-- Debug : 用于调试错误的材质
        |   |-- Base : 基础材质
        |   |-- Utility : 工具材质,如噪波
        |   |-- Weathering : 天气相关的材质
        |-- Attachments : 公用的附件库(有程序逻辑或特效的)
            |-- Common : 通用类型的
            |-- Knife : 特殊类型的武器附件,如匕首
            |   |-- BuleHook : 特殊匕首A
            |   |-- RedBlast : 特殊匕首B

|-- Content
    |-- Project : 项目开发主干(顶级目录)
    |-- Project_Branch01 : 全局分支01 (顶级目录)
    |-- Projectr_Branch02 : 全局分支02 (顶级目录 ; 应当尽可能避免更多分支)
    |-- Project_UnityMigrate : 从Unity中迁移的特定文件(顶级目录)
    |-- MegaScan : 第三方插件引入的(顶级目录)

使用这种目录结构的原因列在下面

2e2 有多个分支时

在项目制作时, 总是能遇到需要从一个主项目中分支迭代出多个版本

如果分支中有任何修改影响了全局的资源, 我们应该遵循 [2.2.4 容易维护DLC、子工程、以及补丁包] 来启用另一个顶级目录进行修改
- 如果分支中仍然出现新的分支, 那么应当是考虑当前项目主干是否合理, 召集团队成员讨论是否需要合并分支状态
如果分支没有对全局资源进行影响, 我们可以直接在当前分支前,新建一个Branch01(按顺序编号)目录,存放当前状态
如果属于并行分支, 应当参照 [版本控制系统] 来进行并行开发
- 注意: 版本控制并不容易, 请做好深思熟虑

注意: 对于是否需要建立分支,请务必做出务实的考虑, 否则您可能面临的是同时在制作两个或者项目, 只是它们看起来名称一样

如果不可避免产生了分支, 应当尽可能将分支控制在如下状况:
如果出现了较多的分支情况,并使用了版本控制系统应当控制在如下情况:

对于版本控制的操作, 请转到 **[版本控制控制] **章节

2.1 文件夹命名

关于文件夹的命名，有一些通用的规范

2.1.1 使用PascalCase大小写规范

文件夹的命名需要遵守PascalCase规范，也就是所有单词的首字母大写，并且中间没有任何连接符。例如DesertEagle, RocketPistol, and ASeriesOfWords.

参照大小写规范.

应当尽可能在不使用前后缀 , 以及子名称的情况下将文件夹名称表述清楚。但如果使用前后缀能够更加清晰得表述目的,就应当使用
- 如:WeaponPickable_Pistol , WeaponPickable_Rifle 这样可以有效提高可读性

2.1.2 不要使用空格

作为对2.1.1的补充，绝对不要在目录名中使用空格。空格会导致引擎以及其他命令行工具出现错误，同样，也不要把你的工程放在包含有空格的目录下面，应该放在类似于D:\Project这样的目录里，而不是C:\Users\My Name\My Documents\Unreal Projects这样的目录。

2.1.3 不要使用其他Unicode语言字符或奇怪的符号

如果你游戏中的角色的名字叫做’Zoë’，那么文件夹要其名为Zoe。在目录名中使用这样的字符的后果甚至比使用空格还严重，因为某些引擎工具在设计时压根就没有考虑这种情况。

顺便说一句，如果你的工程碰到了类似于这篇帖子中的情况，并且当前使用的系统用户名中包含有Unicode字符（比如 Zoë），那么只要把工程从My Documents目录移到类似于D:\Project这种简单的目录里就可以解决了。

记住永远在目录名中只使用a-z, A-Z, 和 0-9这些安全的字符，如果你使用了类似于@, -, _, ,, *, 或者 #这样的字符，难免会碰到一些操作系统、源码管理工具或者一些弱智的工具让你吃个大亏。

2.2 使用一个顶级目录来保存所有工程资源

所有的工程资源都应该保存在一个以工程名命名的目录中。例如你有一个工程叫做’Generic Shooter’，那么所有该工程的资源都应该保存在Content/GenericShooter目录中。

开发者目录Developers不用受此限制，因为开发者资源是跨工程使用的，参照下面的开发者目录中的详细说明。

使用顶级目录的原因有很多。

2.2.1 避免全局资源

通常在代码规范中会警告你不要使用全局变量以避免污染全局命名空间。基于同样的道理，不存在于工程目录中的资源对于资源管理会造成不必要的干扰。

每个属于项目资源都应该有它存在的目的。如果仅仅是为了测试或者体验而使用的资源，那么这些资源应该放在开发者目录中。

2.2.2 减少资源迁移时的冲突

当一个团队有多个项目时，从一个项目中把资源拷贝到另一个项目会非常频繁，这时最方便的方法就是使用引擎的资源浏览器提供的Migrate功能，因为这个功能会把资源的依赖项一起拷贝到目标项目中。

这些依赖项经常造成麻烦。如果两个工程没有项目顶级目录，那么这些依赖项很容易就会被拷贝过来的同名资源覆盖掉，从而造成意外的更改。

这也是为什么EPIC会强制要求商城中出售的资源要遵守同样的规定的原因

执行完Migrate资源拷贝后，安全的资源合并方法是使用资源浏览器中的’替换引用’(Replace References)工具，把不属于工程目录中的资源引用替换掉。一旦资源资源完成完整的合并流程，工程目录中不应该存在另一个工程的顶级目录。这种方法可以_100%_保证资源合并的安全性。

2.2.2e1 举例：基础材质的麻烦

举个例子，你在一个工程中创建了一个基础材质，然后你把这个材质迁移到了另一个工程中。如果你的资源结构中没有顶级目录的设计，那么这个基础材质可能放在Content/MaterialLibrary/M_Master这样的目录中，如果目标工程原本没有这个材质，那么很幸运暂时不会有麻烦。

随着两个工程的推荐，有可能这个基础材质因工程的需求不同而发生了不同的修改。

问题出现在，其中一个项目的美术制作了一个非常不错的模型资源，另一个项目的美术想拿过来用。而这个资源使用了Content/MaterialLibrary/M_Master这个材质，那么当迁移这个模型时，Content/MaterialLibrary/M_Master这个资源就会出现冲突。

这种冲突难以解决也难以预测，迁移资源的人可能压根就不熟悉工程所依赖的材质是同一个人开发的，也不清楚所依赖的资源已经发生了冲突，迁移资源必须同时拷贝资源依赖项，所以Content/MaterialLibrary/M_Master就被莫名其妙覆盖了。

和这种情况类似，任何资源的依赖项的不兼容都会让资源在迁移中被破坏掉，如果没有资源顶级目录，资源迁移就会变成一场非常让人恶心的任务。

2.2.3 范例，模板以及商场中的资源都是安全没有风险的

正如上面2.2.2所讲，如果一个团队想把官方范例、模板以及商城中购买的资源放到自己的工程中，那么这些资源都是可以保证不会干扰现有工程的，除非你购买的资源工程和你的工程同名。

当然也不能完全信任商城上的资源能够完全遵守顶级目录规则。的确有一些商城资源，尽管大部分资源放在了顶级目录下面，但仍然留下了部分资源污染了Content目录

如果坚持这个原则2.2，最糟糕的情况就是购买了两个不同的商场资源，结果发现他们使用了相同的EPIC的示例资源。但只要你坚持把自己的资源放在自己的工程目录中，并且把使用的EPIC示例资源也放在自己的目录中，那么自己工程也不会受到影响。

2.2.4 容易维护DLC、子工程、以及补丁包

如果你的工程打算开发DLC或者子工程，那么这些子工程所需要的资源应该迁移出来放在另一个顶级目录中，这样的结构使得编译这些版本时可以区别对待子工程中的资源。子工程中的资源的迁入和迁出代价也更小。如果你想在子项目中修改一些原有工程中的资源，那么可以把这些资源迁移到子工程目录中，这样不会破坏原有工程。

注意: 所有对主干有不同的改动,应当只在分支操作, 这很重要

2.3 用来做临时测试的开发者目录

开发者目录存在于 /Content/Developers

在一个项目的开发期间，团队成员经常会有一个’沙箱’目录用来做测试而不会影响到工程本身。因为工作是连续的，所以即使这些’沙箱’目录也需要上传到源码服务器上保存。但并不是所有团队成员都需要这种开发者目录的，但使用开发者目录的成员来说，一旦这些目录是在服务器上管理的，总会需要一些麻烦事。

首先团队成员极容易使用这些尚未准备好的资源，这些资源一旦被删除就会引发问题。例如一个做模型的美术正在调整一个模型资源，这时一个做场景编辑的美术如果在场景中使用了这个模型，那么很可能会导致莫名其妙的问题，进而造成大量的工作浪费。

但如果这些模型放在开发者目录中，那么场景美术人员就没有任何理由使用这些资源。资源浏览器的缺省设置会自动过滤掉这个目录，从而保证正常情况下不可能出现被误用的情况。

一旦这些资源真正准备好，那么美术人员应该把它们移到正式的工程目录中并修复引用关系，这实际上是让资源从实验阶段’推进’到了生产阶段。

注意: /Content/Developers此路径不会直接在编辑器中暴露,但是也不能因此滥用此目录

2.4 所有的地图

地图文件非常特殊，几乎所有工程都有自己的一套关于地图的命名规则，尤其是使用了sub-levels或者streaming levels技术时。但不管你如何组织自己的命名规则，都应该把所有地图保存在/Content/Project/Maps

记住，尽量使用不浪费大家的时间的方法去解释你的地图如何打开。比如通过子目录的方法去组织地图资源，例如建立 Maps/Campaign1/ 或 Maps/Arenas，但最重要的是一定要都放在/Content/Project/Maps

这也有助于产品的打版本工作，如果工程里的地图保存的到处都是，版本工程师还要到处去找，就让人很恼火了，而把地图放在一个地方，做版本时就很难漏掉某个地图，对于烘培光照贴图或者质量检查都有利。

2.5 使用`Core`目录存储系统蓝图资源以及其他系统资源

使用/Content/Project/Core这个目录用来保存一个工程中最为核心的资源。例如，非常基础的GameMode, Character, PlayerController, GameState, PlayerState，以及如此相关的一些资源也应该放在这里。

这个目录非常明显的告诉其他团队成员:”不要碰我！”。非引擎程序员很少有理由去碰这个目录，如果工程目录结构合理，那么游戏设计师只需要使用子类提供的功能就可以工作，负责场景编辑的员工只需要使用专用的的蓝图就可以，而不用碰到这些基础类。

例如，如果项目需要设计一种可以放置在场景中并且可以被捡起的物体，那么应该首先设计一个具有被捡起功能的基类放在Core/Pickups目录中，而各种具体的可以被捡起的物体诸如药瓶、子弹这样的物体，应该放在/Content/Project/Placeables/Pickups/这样的目录中。游戏设计师可以在这些目录中定义和设计这些物体，所以他们不应该去碰Core/Pickups目录下的代码，要不然可能无意中破坏工程中的其他功能

2.6 不要创建名为`Assets` 或者 `AssetTypes`的目录

2.6.1 创建一个名为`Assets`的目录是多余的。

因为本来所有目录就是用来保存资源的

2.6.2 创建名为`Meshes`、 `Textures`或者`Materials`的目录是多余的。

资源的文件名本身已经提供了资源类型信息，所以在目录名中再提供资源类型信息就是多余了，而且使用资源浏览器的过滤功能，可以非常便利的提供相同的功能。

比如想查看Environment/Rocks/目录下所有的静态Mesh资源？只要打开静态Mesh过滤器就可以了，如果所有资源的文件名已经正确命名，这些文件还会按照文件名和前缀正确排序，如果想查看所有静态Mesh和带有骨骼的Mesh资源，只要打开这两个过滤器就可以了，这种方法要比通过打开关闭文件夹省事多了。

这种方法也能够节省路径长度，因为用前缀S_只有两个字符，要比使用Meshes/七个字符短多了。

这么做其实也能防止有人把Mesh或者纹理放在Materials目录这种愚蠢行为。

2.7 超大资源要有自己的目录结构

这节可以视为针对2.6的补充

有一些资源类型通常文件数量巨大，而且每个作用都不同。典型的例子是动画资源和声音资源。如果你发现有15个以上的资源属于同一个逻辑类型，那么它们应该被放在一起。

举例来说，角色共用的动画资源应该放在Characters/Common/Animations目录中，并且其中应该还有诸如Locomotion 或者Cinematic的子目录

这并不适用与纹理和材质。比如Rocks目录通常会包含数量非常多的纹理，但每个纹理都都是属于特定的石头的，它们应该被正确命名就足够了。即使这些纹理属于材质库

2.8 材质库`MaterialLibrary`

如果你的工程中使用了任何基础材质、分层材质，或者任何被重复使用而不属于特定模型的材质和纹理，这些资源应该放在材质库目录Content/Project/MaterialLibrary。

这样可以很容易管理这些’全局’材质

这也使得’只是用材质实例’这个原则得以执行的比较容易。如果所有的美术人员都只是用材质实例，那么所有的原始材质都应该保存在这个目录中。你可以通过搜索所有不在MaterialLibrary中的基础材质来验证这一点。

MaterialLibrary这个目录并不是仅能保存材质资源，一些共用的工具纹理、材质函数以及其他具有类似属性的资源都应该放在这个目录或子目录中。例如，噪声纹理应该保存在MaterialLibrary/Utility目录中。

任何用来测试或调试的材质应该保存在MaterialLibrary/Debug中，这样当工程正式发布时，可以很容易把这些材质从删除，因为这些材质如果不删除，可能在最终产品中非常扎眼。

2.9 不要使用空文件夹 `版本控制相关`

根本不应该有任何空文件夹。它们会使内容浏览器变得非常混乱。

如果您发现内容浏览器有一个无法删除的空文件夹，您应该执行以下操作：

1. 确保已经使用源代码管理。
1. 立即在您的项目上运行 Fix Up Redirectors。
1. 导航到磁盘上的文件夹并删除其中的资产。
1. 关闭编辑器。
1. 确保您的源代码控制状态是同步的（即，如果使用 Perforce，请在您的内容目录上运行 Reconcile Offline Work）
1. 打开编辑器。确认一切仍按预期工作。如果没有，请还原，找出问题所在，然后重试。
1. 确保该文件夹现已消失。
1. 向源代码管理提交更改。

3. 蓝图

这一章会专注于蓝图和蓝图的实现。如果可能的话，本规则和Epic官方提供的标准一致。

Remember: Blueprinting badly bears blunders, beware! (Phrase by KorkuVeren)

4. * Mesh 网格体

本节将重点介绍静态网格资产及其内部结构。

4.1 网格体 UV

如果Linter 报告了错误或损坏的UV, 而您似乎无法追踪到它, 去您的项目 Saved/Logs 文件夹中找到.log文件, 它包含了绝大数的错误细节.

4.1.1 所有网格体必须用 UV

很简单, 引擎计算需要UV。所有网格，无论它们如何被使用，都不应缺少 UV。

4.1.2 所有网格都不能在需要光照贴图的UV上重叠

很简单, 你不想要有莫名其妙的黑块。所有网格，无论它们如何使用，都应该具有有效的非重叠 UV。

4.2 应正确设置 LOD

这是基于每个项目的主观检查，但作为一般规则，可以在不同距离看到的任何网格 , 都应具有适当的 LOD。

4.3 模块化组合的资产应该干净利落地捕捉到网格

这是基于每个资产的主观检查，但是任何模块化组合的资产都应根据项目的网格设置直接简单捕捉网格即可组合在一起。

取决于项目 , 决定是基于 2 的幂次方, 还是基于 10 个单位网格的捕捉。但是，如果您正在为项目或者商城创作模块化组合的资产，Epic 的要求是，当网格设置为 10 个单位或更大时，它们必须能直接捕捉到网格。

4.4 所有网格都必须有碰撞体

无论资产是否将用于关卡中的碰撞检测，所有网格都应定义正确的设置碰撞体。

这有助于引擎处理边界计算、遮挡和照明等问题。也应该对碰撞体形成良好的规范。

4.5 所有网格都应正确缩放

这是基于每个项目的主观检查，但是所有资产都应正确缩放到其项目目标比例。

关卡设计师或蓝图开发者不应该需要在编辑器中为了确认正确的大小而调整网格的比例。

任何在引擎中的缩放网格应被视为缩放覆盖，而不是缩放校正。

5. Niagara 粒子系统

本节将重点关注Niagara例子系统的资源与其内部规范。

5.1 不要有空格!绝不!

请查看默认命名原则. 空格在引擎系统中是绝对不被允许的!!

对于 Niagara 系统来说尤其如此，因为当在 Niagara 中使用 HLSL 或其他脚本编写方式时,

如果尝试引用标识符，即使不是不可能，它也会使处理事情变得更加困难。

6. 关卡 / 地图

我们此处将关卡与地图定义为统一概念。

本节将重点介绍关卡资产及其内部结构。

6.1 没有错误或警告

所有级别都应是零错误或加载警告的。如果一个关卡加载时有任何错误或警告，应立即修复它们以防止出现级联错误问题。

您可以使用控制台命令“map check”在编辑器中的打开的关卡上运行错误检查。

注意：Linter 在这方面比编辑器目前更严格，并且会捕获编辑器自行解决的加载错误。

6.2 应当构建照明

在开发过程中，关卡偶尔没有构建照明是正常的。

但是，在进行测试/内部/发版构建或任何要分发的构建时，应始终构建照明 , 不然在运行时总是会有奇怪的错误出现。

6.3 无用户可见的 Z Fighting (深度重叠)

不应在玩家可见的所有区域中 , 出现任何 z-fighting , 因为它们太抢眼了。

6.4 UE商城特定规则 (理论上无用)

如果一个项目要在 UE4 商城上出售，它必须遵循这些规则。

6.4.1 概述关卡

如果您的项目包含应可视化或演示的资产，则您的项目中必须有一个包含名称“Overview”(概述)的地图。

如果是可视化资产，则此概览图应根据 Epic 的指南进行设置。

(https://www.epicgames.com/help/zh-CN/#Required Levels and Maps)

6.4.2 演示关卡

如果您的项目包含应演示或附带某种教程的资产，则您的项目中必须有一个包含名称“Demo”的地图。

此关卡还应包含以某种形式说明如何使用您的项目的文档。

请参阅 Epic 的内容示例项目, 以学习如何制作演示关卡。

[版本控制系统]

1. 版本控制的介绍

[资产制作环节项目组织结构]

资源/资产在制作环节的项目结构设置

设置工程路径

设置工程映射
- 运行***[将当前目录创建为永久网络磁盘P_需管理员.bat]***文件
  - 示例图像
- 运行结束后, 在我的电脑路径下会新增一个盘符P
- 进入盘符P, 此盘符为您的工作环境目录, 请确保所有文件操作在此目录工作
  - 以下图示:

综合 DCC

3Dmax

Maya

Blender

雕刻工具

ZBrush

MudBox

材质处理

Substance Painter

Substance Designer

特效

Houdini

合成/后处理

Nuke

Photoshop

Premiere

离线/射线追踪渲染器

Anorld

Vray

[遵循的标准]

标准单位

三维

在无特殊指定的情况下, 我们将单位默认指定为 CM(厘米)
对于UDK(Unreal Engine) 中的单位换算为 : 每Unreal单位为 1 CM(厘米)
- 详见于 UDK | UnrealUnits (unrealengine.com)
若无指定手系,默认全部以**右手(RH)**坐标系作为参照
若无指定图形RHI实现, 默认全以DirectX作为RHI

二维

在无特殊指定的情况下, 默认使用px(pixle/像素)作为单位
在无特殊指定的情况下, 默认使用72DPI(每英寸的像素)作为解析度参照标准
对于任意可能被用于制作的素材图像, 应当不低于2048px * 2048px @ 72DPI 的分辨率

一维

默认使用有符号单精度浮点, 即 4个字节（32位）

色彩空间

前提

为了简易应对常见情况, 不应当作为色彩管理的准则

三维

在无特殊指定的情况下 , 包含色彩信息时,默认遵循 sRGB 作为色彩空间
若使用了OCIO色彩管理系统, 包含色彩信息时,默认遵循Aces sRGB 作为色彩空间
如非色彩信息, 不使用任何色彩空间, 仅为线性(Linear)

二维

在无特殊指定的情况下 , 包含色彩信息时,默认遵循 sRGB 作为色彩空间
使用OCIO等色彩管理系统时, 默认不做任何直接图像色彩管理, 直接转换为线性, 使用OCIO系统或Lut管理
如非色彩信息, 不使用任何色彩空间, 仅为线性(Linear)