Unreal Engine: Naming Convention Guide
Reading Time: 3 minutesThe goal of this document is to share our internal naming conventions with the community to give everyone something to start out with. Using and getting comfortable with a strict naming convention is essential before your projects grow beyond a few dozen files.
Last Revision: April 12, 2022
First, consider how you are accessing your content. The content browser has powerful filter features making pre-fixes and suffixes less interesting compared to older Unreal Engine editions. However, this still doesn’t apply to the simpler drop-down selection UI for picking class variables, etc. The same can happen when logging asset names in which ‘assetName something error’ occurred, bad naming can make it difficult to track down the origin.
The most complete style guide is available on GitHub by Allar. It’s a style we mostly adopted for our projects.
Coding Standards
Epic has a Coding Standards page that’s worth a read.
Splash Damage has its own extension of the Epic Coding Standard on GitHub. It is well laid out in SplashDamageCodingStandard.h and SplashDamageCodingStandard.cpp. They even included some conventions on Blueprints via a plugin and webpage.
General Naming Rules
- All names in English.
- All asset dependencies should be in the same folder. (except for shared assets)
- Asset type determines prefix.
- Blueprint is BP_assetname_01
- Certain types (eg. textures) use a suffix to specify sub-types.
- T_Grass_01_N for normal maps
- Use underscores to split type from identifier and numeric values.
- SM_DoorHandle_01
- Use numeric values with 2 digits.
- SM_Pipe_01
Content Browser
You can add the asset type to your search query. eg. searching “ship material” will search for assets named ship that may be of type material. This is powerful to nail down specific assets within a group of similar names. (Make sure “Search Asset Class Names” is enabled in the View Options of your Content Browser)
Tip: Use Ctrl+P in the editor/viewport to quickly search for assets without using the Content Browser. This is incredibly powerful when you have properly named your assets!
Content Directories
All game content is placed in a sub-folder. eg. Content/MyGame/UI/… This helps in migrating between projects and splitting your content from marketplace packs that are added like Content/MyMarketplacePack/…
When testing out local assets that are not ready to be used by other members of your team (or perhaps never should be) you can put them in your Developer-folder. You can enable this folder in the view options of the Content Browser. These assets will not show up in searches by other developers
| Sub-Folder | Description |
| Content/MyGame | Top-level folder for all game-specific content. All rows are relative to this folder. |
| ../AI | |
| ../Art | Holds all art content (except for UI/FX) |
| ../Audio | |
| ../Core | |
| ../Characters | |
| ../Characters/Animations | |
| ../FX | |
| ../FX/Flares | Contains Particle systems, materials and textures specific to all types of Flares. |
| ../Maps | Contains all levels including dev-only. |
| ../Maps/Dev/… | Dev-only maps that are not cooked/packaged. |
| ../UI | |
| ../UI/Materials | UI-specific materials. |
| ../UI/Fonts | |
| ../Actions | Example of Action folder that’s specific to my projects. (Actions are like Abilities) |
| ../Expeditions | Example of major feature that deserves its own top-level folder. Mainly holds Blueprints. |
Marketplace Importing
It’s recommended to use a dedicated Marketplace content project to import the packs first. This is your staging area before migrating pieces into your main project. This lets you review and filter out unwanted content early.
Asset Naming
Lyra Starter Game
Lyra Starter Game is a new project that shipped with the release of Unreal Engine 5.0. They use the Gameplay Ability System which introduces certain asset types and their own naming. Here are some of the prefixes they use in the project.
| Prefix | Asset Type |
|---|---|
| GA_ | Gameplay Abilities |
| GE_ | Gameplay Effects |
| GCN_ | Gameplay Cue Notifies (UGameplayCueNotify) |
| GCNL_ | Latent Gameplay Cue Notifies (Inherits from AGameplayCueNotify_Actor and subclasses.) |
| Phase_ | Game Phase Abilities |
| AbilitySet_ | Ability Set |
| IA_ | Input Action (Enhanced Input) |
| InputData_ | (Lyra) Input Config |
| W_ | Widget (Blueprint) UI |
| B_ | All other blueprints such as pawn types, item spawners, etc. |
Prefixes
Somes tables are temporarily broken and incomplete, please check out the link above for a more complete list of naming tables.
[table sort=”asc”]
Asset Type, Prefix, Example, Comment
Blueprint, BP_, BP_WallLight_01, Except for derived common classes: HUD / GameMode / Character
Blueprint Interface, BPI_, BPI_InventoryItem_01,
Material, M_, M_Grass_01,
Material Instance, MI_, MI_Grass_01,
Material Function, MF_, MF_CheapContrast, Not numbered
Material Parameter Collection, MPC_, MPC_EnvironmentSettings_01,
Static Mesh, SM_, SM_Wall_01,
Skeletal Mesh, SK_, SK_Character_01,
Texture, T_, T_Grass_01_D, Has suffix for texture types. See suffixes table.
Particle System, P_, P_Fire_01,
Physics Material, _PhysMat, Dirt_PhysMat, Not numbered
Sound, S_, S_HitImpact_Mono_01, Include _Mono or _Stereo designations
Sound Cue, S_*_Cue, S_HitImpact_01_Cue,
Attenuation, _att, Explosion_att,
Enumeration, E, EWeaponType, Not numbered. Similar to convention in code (enum EWeaponType)
Render Target, RT_, RT_CameraCapturePoint_01,
Vector/Float/Color Curve, Curve_, Curve_Recoil_AK47,
Camera Shake, CamShake_, CamShake_Landed,
User Widget, Widget_, Widget_EnergyBar,
Font, Font_, Font_Roboto48, Font size is included in name.
[/table]
Suffixes
Textures
Texture types all use the T_ prefix.
[table sort=”asc” width=”300px”]
Texture type, Suffix
Diffuse/Color Map, _D
Normal Map, _N
Emissive Map, _E
Mask Map, _M
Roughness Map, _R
Metallic Map, _MT
Specular, _S
Displacement, _DP
Ambient Occlusion, _AO
Height Map, _H
Flow Map, _F
Light Map (custom), _L
[/table]
Animation
These types have no prefix. These names are pretty standard to how the engine automatically names them on import / creation.
| Type | Suffix |
| Animation Blueprint | _AnimBP |
| Physics Asset | _PhysicsAsset |
| Skeleton | _Skeleton |
| BlendSpace | _BlendSpace |
| AnimMontage | _Montage |
Hi Tom,
In the note at the beginning you have stated that Gamemakin Style guide by Allar is what you have “mostly adopted for [y]our projects”, but I can see differences between this guide and the Gamemakin one. Also, some tables are broken.
So I was wondering if this guide was outdated and whether you guys recommend Gamemakin guide officially for any future/current projects.
I recently added the style guilde link for a more complete guide. I don’t completely follow his guide either, but it’s a very good start for people to look at, adopt and adapt. When I get some time I’d like to revisit this guide and completely update it to our current conventions.
Any chance to see an update on the current structure?
While they are widely used, i don’t really like the asset type prefix.
In many places you see the prefixes used with directory structures based on content type, which seems redundant. When you use them with a directory structure by object or content structure, like you describe, you do indeed need something to avoid naming duplicates.
But even then it makes much more sense to me to use asset type suffixes, not prefix.
Starting with the object name, and having an asset type suffix, all relevant files for an object are alphabetically sorted together. The emphasis is on the object name, not it’s type.
Unless Epic gives us an option to sort after the suffix…
When you want to see all assets per type in a given folder just use the asset type filters.
They also read more naturally. Beam_P reads as Beam particle system, Beam_M as Beam material. Not the other way around.
Assets that already have a suffix in the prefix convention, just keep the asset type suffix last. So for example Rocks_D_T for Rocks diffuse texture, or even Rocks_01_D_T
Going to use this convention for a while…
Interesting thought! We’re currently reviewing our own content convention, with the content browser being quite powerful in properly filtering by type, names etc. it may indeed be less valuable to have prefixes and instead rely post on suffixes for additional type info.
Idea here is that once we settled on an updated convention we’ll share it again.
Hey Tom! I was wondering if you have changed your mind about prefixes/suffixes. I think that they are still useful when you are not using UE4 since all the files are .uasset so there is no way to tell the type of asset. However, I am not sure if it’s worth the effort
Are you still using them for your projects in the same way?
Good question! I still use suffixes and prefixes, including sometimes for my sub-classed blueprints, I use “BP” a lot less and instead more descriptive words like Action_ or Terminal_ShieldGenerator etc.
Since the search utility is clever enough to allow asset type in your search (eg. “widget” will find UMG widgets) it’s less important to use prefixes for some types (I don’t use it consistently in my textures or sound assets anymore for example)
I’ll see if I can do a follow-up, for now this page is somewhat deprecated as Allar’s Style Guide on github is a more complete version.
I see. Yeah, we are also following Allar’s while we find our own sweet spot for these things which might be closer to what you describe. Thank you Tom!
Hi Tom,
thanks for this article. Do you use any style check tools? We are currently trying to modify our programming workflow and checking out tools like Cpplint and CppChecker. Do you have any experience with these?
Hi Pascal,
Haven’t used any code style checkers recently. The ones I have were for C# unfortunately.
– Tom
I’d be interested in seeing that update!
This one seems at least one step ahead =]
https://github.com/Allar/ue4-style-guide
True, Allar did a great job! This page could use some updating, with how we work at the current studio, a lot has changed since it was first published over 2 years ago (with some revisions after)
– Tom
I’ve bumped in to file path restrictions in libraries following this pattern. I just drop the underscores where possible and depend on character case to (hopefully) separate. If Epic can expand the path size to something more realistic I can see it.
Ahh, the merits of NTFS.
(just in case a machine learning algorithm miss interprets that, NTFS SUCKS!!!)
I’ll tend to just install my files in a nice shortly named directory in the root of the file system.
Yep. Company purchased a sound library. A good one. But due to the long file names (with LOTS of underscores that are unnecessary) I have to move the project files to the HDD root to get Unreal not to complain if I use the library (I need to notify the library producer of this issue probably as well).
Capital letters and structured file names work just fine without extra characters. This isn’t an NTFS issue though but a restriction that the Unreal system imposes on file name length. If it was NTFS having the problem I’d have the OS complain when I manipulate/move these files unless I use another utility. That’s why I complained about Epic not Microsoft. Epic sets a limit of 180 characters, Windows has a limit of 259. Epic says they are doing it for cross-OS compatibility but I don’t know of any out there that are that short in file name lengths.
The 259 character limit depends on the Windows API being used. It can be much higher.
Again, the 259 character limit of the Windows API isn’t the problem we’ve run into; it has no relationship to the file path limit issue; that’s entirely on Epic’s side. It doesn’t matter if it’s OS X, Win 10, iOS, Linux of some flavor, etc. The file size limit in the Unreal engine, last I knew, remains 180. I STILL have team members using underscores as “spaces”. It’s hard to break them of the tendency. 🙁