1. 项目概述为什么UE5项目需要一个“家规”刚接触虚幻引擎5UE5的朋友或者是从小项目转向团队协作的开发者可能都经历过这样的混乱时刻在内容浏览器里翻箱倒柜只为找一个昨天刚做好的材质球或者因为同事把一个蓝图命名为“NewBlueprint”导致版本冲突半天的工作白费。这不仅仅是文件管理的问题它直接拖慢了整个项目的迭代速度增加了沟通成本甚至可能引发严重的生产事故。今天要聊的就是UE5项目开发中那个看似基础却至关重要的“家规”——资产命名规范与目录结构的最佳实践。这绝不是什么纸上谈兵的理论。一个清晰、一致的命名规范和目录结构是项目可维护性、团队协作效率和资产复用性的基石。想象一下一个拥有成千上万个资产模型、材质、蓝图、动画等的中大型项目如果没有统一的规则内容浏览器很快就会变成一个无法管理的垃圾场。规范的命名能让机器引擎的引用系统和人都能快速理解资产的用途、类型和状态。而合理的目录结构则像一座图书馆的分类系统让你能按图索骥而不是大海捞针。在UE5的语境下这套规范尤其重要。因为UE5引入了诸如Nanite、Lumen、World Partition等革命性技术项目规模和复杂度可以呈指数级增长。混乱的资产管理会直接抵消这些技术带来的性能和生产效率优势。接下来我将结合官方建议、行业惯例以及我个人在多个项目中踩过的坑为你拆解一套行之有效的实践方案。无论你是独立开发者还是团队中的技术美术、TA或主程这套“家规”都能让你的项目开发事半功倍。2. 核心设计思路从混乱到秩序的构建原则制定命名规范和目录结构不是简单地列一张表让大家遵守。其背后是一套完整的设计哲学目的是为了解决特定问题。我们需要先理解核心原则才能灵活应用而不是生搬硬套。2.1 核心目标可发现性、可读性与可维护性所有规范设计的最终目标都指向这三个词。可发现性团队成员包括未来的你能否在10秒内找到需要的资产这依赖于清晰的目录层级和包含关键信息的文件名。例如一个角色武器纹理放在Assets/Characters/Hero/Weapons/Textures/下并被命名为T_Hero_Rifle_D其位置和含义一目了然。可读性在不打开资产的情况下仅通过文件名和路径就能理解其大致内容和用途。BP_Interactable_Door_A显然比Door_01包含了更多信息它是一个蓝图BP属于可交互物Interactable具体是门Door并且可能有A版本变体。可维护性当需要批量修改、引用检查或资产迁移时良好的结构能极大降低操作成本和出错风险。例如所有角色共用的动画资源放在一个共享目录当动画系统更新时只需修改一处所有角色都能受益。2.2 命名规范的核心前缀系统与上下文描述Epic官方文档提供了一套基于前缀的命名规范其格式为[AssetTypePrefix]_[AssetName]_[Descriptor]_[OptionalVariantLetterOrNumber]。这套系统的精髓在于将资产的类型信息放在了最前面。为什么前缀如此重要在内容浏览器默认的列表视图中资产是按名称字母顺序排列的。如果所有蓝图都以“BP_”开头所有材质都以“M_”开头那么同类型的资产就会自动归类在一起便于查找和批量操作。这比依赖文件夹分类更直接因为资产引用是跨文件夹的。AssetTypePrefix资产类型前缀这是资产的“姓氏”直接表明其根本类型。如BP_代表蓝图M_代表材质SK_代表骨骼网格体。这确保了在搜索、过滤或脚本处理时能快速定位到某一类资产。AssetName资产名称这是资产的“名字”通常指代其所属的逻辑实体或功能模块。例如一个属于“英雄”角色的资产其名称部分可以是Hero。Descriptor描述符这是资产的“中间名”或“修饰词”提供了关于资产用途或属性的额外上下文。对于纹理描述符可能是D漫反射、N法线、RMA粗糙度-金属度-环境光遮蔽对于蓝图可能是Interactable、Pickup、Widget。OptionalVariant可选变体当存在多个版本时使用如_A、_B或_01、_02。用于区分迭代版本或不同变体如不同颜色的同一把武器。2.3 目录结构设计逻辑分层与物理隔离目录结构是命名规范的物理体现它应该反映项目的逻辑架构而不仅仅是资产类型的简单堆砌。一个好的结构是“自解释”的。逻辑分层原则目录应该从抽象到具体从通用到专用。一个常见的顶级结构可能是Content/ProjectName/项目根目录以项目名命名避免与其他项目插件资产混淆。Art/所有美术资源。Core/核心系统与框架游戏模式、玩家控制器、基础类等。Maps/所有游戏关卡。UI/所有用户界面相关资源。Audio/所有音频资源。Blueprints/如果蓝图数量巨大可以单独提出否则可按功能分散到各模块。物理隔离考量除了逻辑清晰还需考虑团队工作流。例如将Art/目录下的Source/原始高模、PSD等和Engine/导入UE后的资产分开可以方便美术和程序/策划并行工作互不干扰。使用.umap文件进行关卡流送时相关的子关卡和持久性关卡应放在相邻目录。注意避免创建过深的目录层级建议不超过5-6级。过深的路径会导致资产引用路径过长增加管理复杂度有时甚至可能触发Windows的路径长度限制。同时也要避免过于扁平的结构所有资产扔在一个文件夹里那会失去分类的意义。3. 资产命名规范详解从通用到专项理解了原则我们来深入每一类资产的命名细节。我将官方表格作为基础并结合实际项目中的扩展和变通进行说明。3.1 通用资产命名规则这是最常用的一套前缀适用于大多数基础资产类型。材质Material:M_示例:M_BrickWall_Wet,M_Glass_Stained说明: 基础材质球。名称应描述其表现的表面特性。材质实例Material Instance:MI_示例:MI_BrickWall_Wet_01,MI_Glass_Stained_Blue说明: 材质实例是材质的参数化变体。通常在其父材质名后追加变体描述。如果父材质是M_Metal_Basic一个生锈的变体可以叫MI_Metal_Basic_Rusted。静态网格体Static Mesh:SM_示例:SM_Props_Crate_Wooden,SM_Arch_Wall_Stone_01说明: 用于环境、道具等非动画模型。描述符应清晰说明其是什么Crate以及可能材质Wooden。骨骼网格体Skeletal Mesh:SK_示例:SK_Char_Hero,SK_Creature_Dragon说明: 用于角色、生物等需要动画的模型。纹理Texture:T_示例:T_Char_Hero_BaseColor,T_Prop_Barrel_Normal,T_Env_Ground_RMA说明: 纹理的命名是描述符大显身手的地方。强烈建议使用标准的后缀来描述纹理类型_D/_Albedo/_BaseColor: 漫反射/反照率/基础色贴图。_N/_Normal: 法线贴图。_R/_Roughness: 粗糙度贴图。_M/_Metallic: 金属度贴图。_AO/_AmbientOcclusion: 环境光遮蔽贴图。_RMA: 将粗糙度(R)、金属度(M)、环境光遮蔽(AO)打包在一张纹理的RGB通道中这是一种高效的做法。_H/_Height: 高度图。_E/_Emissive: 自发光贴图。_MSK/_Mask: 遮罩贴图。使用这些后缀配合引擎的纹理自动识别功能可以简化材质设置流程。物理资产Physics Asset:PHYS_示例:PHYS_SK_Char_Hero说明: 通常关联一个骨骼网格体因此名称最好能体现其对应的网格体如PHYS_[对应SK名称]。后期处理材质Post Process Material:PPM_示例:PPM_Vignette,PPM_GlobalColorGrading说明: 用于屏幕后处理效果的专用材质。3.2 蓝图类资产命名规则蓝图是UE中的可编程资产种类繁多前缀有助于快速区分其功能。蓝图Blueprint Class:BP_示例:BP_Character_Player,BP_Door_Automatic,BP_Pickup_HealthPack说明: 所有继承自Actor或其他类的可放置蓝图。名称应清晰表明其是什么Door以及可能的子类Automatic。控件蓝图Widget Blueprint:WBP_示例:WBP_HUD_Main,WBP_Menu_Start,WBP_Inventory_Slot说明: 用于UI界面。建议名称体现其所在的界面层级HUD, Menu和具体功能Main, Inventory。动画蓝图Animation Blueprint:ABP_示例:ABP_Char_Hero_Locomotion,ABP_Creature_Spider说明: 控制骨骼网格体动画逻辑的蓝图。通常关联一个骨骼网格体。蓝图接口Blueprint Interface:BI_示例:BI_Interactable,BI_Damageable说明: 定义一组契约供其他蓝图实现。名称通常以“able”结尾描述一种能力或状态。Actor组件Actor Component:AC_示例:AC_HealthSystem,AC_Inventory说明: 可复用的功能模块可以添加到任何Actor上。名称应描述其提供的系统功能。结构Struct:F_(或S_, 但官方推荐F_源自C中的FStruct)示例:F_ItemData,F_DialogueEntry说明: 用于组织数据的容器。在纯蓝图项目中S_也被广泛接受和理解。枚举Enumeration:E_示例:E_ItemType,E_CharacterState数据表Data Table:DT_示例:DT_Weapons,DT_NPC_Dialogue说明: 存储结构化数据的资产通常用DT_加数据主题命名。曲线表Curve Table:CT_示例:CT_DamageScaling,CT_Experience说明: 存储浮点曲线数据的资产。3.3 动画与特效资产命名规则动画和特效资产关系紧密且往往数量庞大规范的命名至关重要。动画序列Animation Sequence:AS_示例:AS_Char_Hero_Run,AS_Char_Hero_Jump_Start说明: 单个动画剪辑。名称应包含角色名和动作描述。对于复杂动作可以加上阶段如_Start,_Loop,_End。动画蒙太奇Animation Montage:AM_示例:AM_Char_Hero_Attack_Combo,AM_Char_Hero_HitReaction说明: 用于组合或混合多个动画序列或添加通知。命名类似动画序列。混合空间Blend Space:BS_示例:BS_Char_Hero_Locomotion_2D,BS_Char_Hero_AimOffset骨架Skeleton:SKEL_示例:SKEL_Char_Humanoid,SKEL_Creature_Quadruped绑定Rig:Rig_示例:Rig_SK_Char_HeroNiagara系统Niagara System:FXS_示例:FXS_Explosion_Fire,FXS_Impact_Concrete说明: 完整的粒子效果系统。Niagara发射器Niagara Emitter:FXE_示例:FXE_Sparks,FXE_SmokeTrail说明: 粒子系统内的单个发射器模块。Niagara函数Niagara Function:FXF_示例:FXF_VelocityNoise,FXF_ColorOverLife3.4 其他专项资产命名规则随着项目深入还会遇到一些特定类型的资产。关卡序列Level Sequence:LS_示例:LS_Cinematic_Intro,LS_Gameplay_BossEntrance说明: 用于过场动画或复杂的游戏事件序列。媒体源/播放器Media Source/Player:MS_,MP_示例:MS_Video_Intro,MP_Background关卡快照Level Snapshot:SNAP_示例:SNAP_LevelDesign_V1远程控制预设Remote Control Preset:RCP_示例:RCP_Lighting_DayTime实操心得不要试图一次性记住所有前缀。最好的方法是团队内部维护一份共享的“命名规范速查表”可以是一个Wiki页面或项目根目录下的README文件并随着项目进展和新资产类型的出现共同更新。在项目初期就应在引擎中创建几个示例资产让所有成员直观感受命名效果。4. 目录结构最佳实践构建项目的骨架命名规范解决了“单个资产是谁”的问题目录结构则要解决“所有资产如何安家”的问题。一个优秀的目录结构应该像城市的规划图功能区划分明确道路引用关系清晰。4.1 推荐的项目根目录结构以下是一个适用于中小型到大型游戏的通用目录结构模板你可以根据项目类型FPS、RPG、解谜等进行调整。Content/ ├── [ProjectName]/ # 项目根文件夹以项目名命名如 MyGame │ ├── Art/ # 所有美术资源 │ │ ├── Characters/ # 角色相关 │ │ │ ├── Hero/ # 主角 │ │ │ │ ├── Meshes/ # 网格体 (SK_, SM_) │ │ │ │ ├── Textures/ # 纹理 (T_) │ │ │ │ ├── Materials/ # 材质 (M_, MI_) │ │ │ │ ├── Animations/ # 动画 (AS_, AM_, ABP_) │ │ │ │ └── Blueprints/ # 角色专属蓝图 (BP_) │ │ │ ├── Enemy/ │ │ │ │ └── ... (类似结构) │ │ │ └── Common/ # 角色共用资源如共享骨架、通用动画 │ │ ├── Environments/ # 环境美术 │ │ │ ├── Props/ # 可放置道具 │ │ │ ├── Architecture/ # 建筑结构 │ │ │ ├── Foliage/ # 植被 │ │ │ ├── Terrain/ # 地形材质与图层 │ │ │ └── Sky/ # 天空球、HDRI等 │ │ ├── Effects/ # 视觉特效 │ │ │ ├── Particles/ # Niagara系统 (FXS_) │ │ │ ├── Materials/ # 特效专用材质 │ │ │ └── Textures/ # 特效贴图噪声、梯度等 │ │ └── UI/ # 用户界面美术或单独放在顶级UI目录 │ │ ├── Icons/ │ │ ├── Fonts/ │ │ └── Textures/ │ ├── Core/ # 核心系统与框架 │ │ ├── Blueprints/ # 基础游戏框架蓝图 │ │ │ ├── GameModes/ │ │ │ ├── PlayerControllers/ │ │ │ ├── GameStates/ │ │ │ ├── PlayerStates/ │ │ │ └── Interfaces/ # 蓝图接口 (BI_) │ │ ├── Components/ # 通用Actor组件 (AC_) │ │ ├── Data/ # 数据资产 │ │ │ ├── DataTables/ # 数据表 (DT_) │ │ │ ├── Structures/ # 结构 (F_) │ │ │ └── Enums/ # 枚举 (E_) │ │ └── Utilities/ # 工具类、函数库蓝图 │ ├── Maps/ # 游戏关卡 │ │ ├── Main/ # 主关卡、持久性关卡 │ │ ├── Levels/ # 子关卡用于流送 │ │ │ ├── Forest_Zone1/ │ │ │ ├── Forest_Zone2/ │ │ │ └── Dungeon_Interior/ │ │ ├── Menu/ # 菜单界面关卡 │ │ └── Tests/ # 测试用关卡 │ ├── Audio/ # 音频资源 │ │ ├── Music/ │ │ ├── SFX/ │ │ └── Dialogue/ │ ├── UI/ # 用户界面逻辑如果与美术UI分开 │ │ ├── Widgets/ # 控件蓝图 (WBP_) │ │ └── Styles/ # 样式、字体等 │ └── Plugins/ # 项目专用插件如果有 │ └── [PluginName]/ │ └── Content/ └── _Shared/ # 可选跨项目共享资产库 └── ...4.2 目录结构设计解析与权衡这个结构体现了几个关键设计思想按功能/内容划分而非按资产类型这是最重要的原则。不要创建名为All_Blueprints、All_Materials的文件夹。因为一个角色的材质、网格体、动画在逻辑上属于一个整体分开存放会极大增加管理难度。应该按Characters/Hero/这样的逻辑单元来组织其下再按类型分子目录。Core/目录的独立性这里存放的是游戏运行的“引擎”是策划和美术通常不需要直接修改的部分。将其隔离出来有利于程序进行版本控制和架构维护也避免了无关人员误操作。Maps/目录与World Partition/关卡流送对于使用World Partition的大型开放世界Levels/子目录下的每个文件夹可以对应一个数据层Data Layer或一个地理区域。将子关卡组织在对应的文件夹内便于按区域加载和管理。Art/目录的细分在Art/下按Characters,Environments,Effects等大类划分符合美术生产管线。每个大类下再按具体资源如一个角色、一个场景套装建立文件夹内部再按资产类型细分。这种“项目-角色-资产类型”的层级平衡了查找效率和结构清晰度。对待_Shared或Common目录对于多个角色或环境共用的资源如一套PBR材质球库、通用粒子效果、标准人体骨架建立一个_Shared或Common目录是非常有价值的。使用下划线前缀如_Shared可以让它排序在内容浏览器列表的顶部易于找到。踩坑提醒切忌在项目中期大规模重构目录结构移动大量已被引用的资产会导致引用断裂修复起来极其痛苦。务必在项目启动的预生产阶段就和团队一起确定好目录结构。如果必须调整务必使用引擎内的“迁移Migrate”功能或专业的重构工具并在操作前备份项目。4.3 特殊资产与插件管理第三方插件资产尽量保持插件自带的资产在其原始目录内如Plugins/SomePlugin/Content/。不要随意将插件资产移动到你的项目目录中除非你确定需要修改它们且愿意承担后续插件更新时可能发生的冲突。Quixel Megascans等桥接资产使用Quixel Bridge导入的资产建议统一导入到一个固定的目录例如Content/ProjectName/Art/External/Megascans/并在其下按表面、植物、3D资产等进一步分类。这有助于区分自制资产和外部采购资产。源代码与蓝图版本控制如果你的项目使用CSource/目录应放在项目根目录与.uproject文件同级而不是Content/下。确保你的版本控制如Git正确忽略了Binaries/、Intermediate/、Saved/、DerivedDataCache/等文件夹并正确包含了Content/、Source/和.uproject文件。5. 实操流程从零搭建规范化的项目框架理论说再多不如动手做一遍。下面我们一步步演示如何在一个全新的UE5项目中建立并贯彻这套规范。5.1 第一步项目初始化与根目录创建创建新项目启动UE5选择适合你项目的模板如第三人称游戏。给项目起一个明确的英文名例如MyActionGame。这将是你的项目标识。清理默认内容许多模板会自带示例内容。在确认不需要后可以在内容浏览器中删除Content/下的示例文件夹如ThirdPerson/、ThirdPersonBP/等。但注意保留Content/本身。创建项目根文件夹在Content/下创建一个与项目同名的文件夹MyActionGame/。今后所有项目自有资产都应放在这个文件夹内。这是隔离项目资产与引擎或插件资产的好习惯。创建核心骨架目录在MyActionGame/内创建第一级子文件夹Art/,Core/,Maps/,Audio/,UI/。此时你的结构应该是Content/ └── MyActionGame/ ├── Art/ ├── Core/ ├── Maps/ ├── Audio/ └── UI/5.2 第二步细化Art目录与创建示例资产规划Art子结构根据你的游戏类型细化Art/。假设我们是一个动作游戏先创建Characters/和Environments/。创建第一个英雄角色结构进入Art/Characters/创建Hero/。在Hero/内创建Meshes/,Textures/,Materials/,Animations/。导入并规范命名第一个资产从你的DCC工具如Maya, Blender导出一个英雄角色的FBX文件。将其导入到MyActionGame/Art/Characters/Hero/Meshes/。导入时在导入选项中可以重命名。根据规范将其命名为SK_Char_Hero。导入后引擎会自动创建骨架和物理资产。检查它们的命名骨架Skeleton应该被自动命名为SKEL_SK_Char_Hero或类似。如果不对手动重命名为SKEL_Char_Hero。物理资产Physics Asset同理重命名为PHYS_SK_Char_Hero。关键操作重命名时务必使用内容浏览器中的“重命名Rename”功能F2而不是在操作系统文件管理器中修改。引擎的重命名功能会自动更新所有对该资产的引用。创建并命名材质在MyActionGame/Art/Characters/Hero/Materials/中右键创建材质。将其命名为M_Char_Hero。这是一个基础材质。基于它创建一个材质实例命名为MI_Char_Hero_V1并将其应用到SK_Char_Hero上。导入并命名纹理将角色的漫反射贴图导入到MyActionGame/Art/Characters/Hero/Textures/。命名为T_Char_Hero_BaseColor。同理导入法线贴图命名为T_Char_Hero_Normal。5.3 第三步搭建Core系统框架创建游戏框架蓝图进入MyActionGame/Core/Blueprints/需先创建Blueprints文件夹。创建蓝图类选择GameMode Base命名为BP_GameMode_MyAction。保存到Core/Blueprints/GameModes/。同理创建BP_PlayerController_Main,BP_GameState_Main,BP_PlayerState_Main并放入相应文件夹。创建角色蓝图在MyActionGame/Art/Characters/Hero/下创建Blueprints/文件夹。基于Character类创建蓝图命名为BP_Char_Hero并保存于此。在BP_Char_Hero的网格体组件中选择前面创建的SK_Char_Hero。为其动画类选择或创建一个ABP_Char_Hero保存到Animations/文件夹。配置默认类打开项目设置Project Settings-地图和模式Maps Modes。在Default Modes下将Default GameMode设置为BP_GameMode_MyAction。在Selected GameMode下确保Player Controller Class等已自动关联因为我们在BP_GameMode_MyAction中设置了它们。如果没有手动指定。5.4 第四步建立Maps与测试流程创建关卡目录在MyActionGame/Maps/下创建Main/,Levels/,Tests/。设置主关卡将默认的ThirdPersonMap或你创建的第一个关卡另存为L_Main关卡通常以L_或Level_为前缀但非强制并移动到Maps/Main/文件夹。将其设为项目启动地图Project Settings - Maps Modes - Default Maps。创建测试关卡在Maps/Tests/中创建一个新关卡命名为Test_Character。专门用于测试角色移动、动画和功能。这能保持主关卡的整洁。至此一个具有清晰规范雏形的项目框架就搭建起来了。所有新资产都应遵循此框架进行创建和存放。6. 常见问题、维护技巧与高级策略即使建立了规范在长期开发中也会遇到各种问题。下面是一些实战中总结的疑难解答和维护技巧。6.1 常见问题排查速查表问题现象可能原因解决方案迁移资产后引用丢失红字1. 在操作系统直接移动了资产文件。2. 目标项目缺少依赖的父类或资源。1.永远使用内容浏览器的“迁移(Migrate)”功能在不同项目间移动资产。它会自动处理引用。2. 确保目标项目已包含所有必要的父类、插件和基础资源。重命名资产后蓝图编译错误蓝图节点引用的资产名称未自动更新。1. 使用引擎内重命名F2而非外部重命名。2. 如果已出错在蓝图编辑器中通过右键点击错误节点 - “查找引用”手动选择正确的新资产。内容浏览器搜索不到资产1. 资产命名未使用规范前缀。2. 资产位于被过滤掉的路径或收藏夹外。3. 搜索词不准确。1. 使用前缀如BP_进行过滤搜索。2. 检查内容浏览器的路径视图和过滤器设置。3. 利用描述符进行搜索如搜索“Rifle”查找所有相关资产。团队成员命名不一致缺乏统一的规范文档或审查流程。1. 建立并共享本文档这样的规范。2. 在项目初期进行培训。3. 定期进行内容审查或在版本控制提交时设置简单的命名检查钩子Hook。文件夹数量爆炸难以管理目录层级设计不合理或为每个微小变体都创建了新文件夹。1. 遵循“逻辑分组”原则不要过度细分。同类资产数量少于5个时可考虑合并文件夹。2. 使用资产命名中的“变体”后缀如_A,_B来区分同一文件夹内的相似资产而不是新建文件夹。插件更新后资产冲突修改了插件自带的资产并将其移出了插件目录。1. 尽量避免修改插件核心资产。如需定制应创建派生资产如材质实例放在自己项目目录。2. 如果必须修改做好笔记以便在插件更新后手动合并更改。6.2 维护与扩展技巧使用收藏夹Favorites和元数据Metadata对于经常访问的深层目录如Core/Blueprints/Interfaces/可以将其添加到内容浏览器的收藏夹。此外可以为资产添加元数据标签在资产详情面板实现跨物理文件夹的智能过滤和搜索。建立资产前缀检查工具高级对于大型团队可以考虑编写一个简单的编辑器工具Editor Utility Widget或使用Python脚本定期扫描项目内容检查资产命名是否符合规范并生成报告。处理遗留项目如果你接手了一个没有规范的老项目大刀阔斧地重构风险极高。建议增量改进对于所有新创建的资产严格执行新规范。局部整理当需要频繁修改某个混乱的模块时可以对该模块进行一次性重构并立即测试所有功能。使用重定向器Redirectors如果必须移动大量资产引擎可能会自动生成重定向器以保持旧引用有效。但重定向器过多会影响加载性能应定期使用“编辑器菜单 - 文件 - 修复重定向器”来清理。文档化与团队守则将命名规范与目录结构写成团队Wiki的第一页。新成员入职的第一件事就是阅读并理解它。在代码审查Code Review中也应加入对资产命名和存放位置的审查。6.3 适应不同项目规模的策略小型项目/独立游戏可以简化结构。例如可以省略Core/目录将核心蓝图放在项目根目录下。但命名规范必须坚持这是为项目未来可能的发展打下好基础。大型项目/AAA团队结构需要更精细。可能会按功能模块划分如Gameplay/,AI/,Vehicles/每个模块下再有自己的Art,Blueprints等。可能需要专门的工具团队来维护资产命名规范和自动化检查流程。纯蓝图项目 vs. C项目在C项目中Core/目录下的很多功能可能会由C类实现蓝图仅作为封装或数据配置。此时Core/Blueprints/下的内容可能会减少更多是数据资产DT_,F_和组件AC_。我个人在多个项目中实践下来的最深体会是规范的价值不在于它本身有多完美而在于整个团队能否始终如一地执行。在项目初期多花一两个小时讨论并确定规范在每次创建资产时多花几秒钟思考并应用规范所避免的后期混乱和浪费的时间将是成百上千倍的。这套“家规”看似约束实则是创造力的解放让你和你的团队能将精力真正集中在创作本身而不是在文件的迷宫中浪费时间。
