[S-Unreal] Unreal Style Guidelines

In this article:

Overview

[G-Production-001] Principles

[Production-001.1] If your project already has a style guide, you should follow it

If you are working on a project or with a team that has a pre-existing style guide, it should be respected. Any inconsistency between an existing style guide and this guide should defer to the existing.

Style guides should be living documents. You should propose style guide changes to an existing style guide as well as this guide if you feel the change benefits all usages.

"Arguments over style are pointless. There should be a style guide, and you should follow it."

Rebecca Murphey

[Production-001.2] All structure, assets, and code in any project should look like a single person created it, no matter how many people contributed

Moving from one project to another should not cause a re-learning of style and structure. Conforming to a style guide removes unneeded guesswork and ambiguities.

It also allows for more productive creation and maintenance as one does not need to think about style. Simply follow the instructions. This style guide is written with best practices in mind, meaning that by following this style guide you will also minimize hard to track issues.

[Production-001.3] Friends do not let friends have bad style

If you see someone working either against a style guide or no style guide, try to correct them.

When working within a team or discussing within a community such as Unreal Slackers, it is far easier to help and to ask for help when people are consistent. Nobody likes to help untangle someone's Blueprint spaghetti or deal with assets that have names they can't understand.

If you are helping someone whose work conforms to a different but consistent and sane style guide, you should be able to adapt to it. If they do not conform to any style guide, please direct them here.

[Production-001.4] A team without a style guide is no team of mine

When joining a team of project, one of your first questions should be "Do you have a style guide?". If the answer is no, you should be skeptical about their ability to work as a team.

[Production-001.5] Don't Break The Law

Agate is not a lawyer, but please don't introduce illegal actions and behavior to a project, including but not limited to:

Don't distribute content you don't have the rights to distribute.
Don't infringe on someone else's copyrighted or trademark material.
Don't steal content.
Follow licensing restrictions on content, e.g. attribute when attributions are needed.

[S-Unreal-001] Terminology

[Unreal-001.1] Cases for letter

There are a few different ways you can CaseWordsWhenNaming. Here are some common casing types:

PascalCase Capitalize every word and remove all spaces, e.g. DesertEagle, StyleGuide, ASeriesOfWords.

camelCase The first letter is always lowercase but every following word starts with uppercase, e.g. desertEagle, styleGuide, aSeriesOfWords.

Snake_case Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g. desert_Eagle, Style_Guide, a_Series_of_Words.

[Unreal-001.2] Incremental Number

The process of increasing a numeric value. Used in the same name asset, increment number must added at the end of the file before asset type suffix, e.g. SomeAsset_01, SomeAsset_02``.

[Unreal-001.3] Z-Fighting

Z-fighting, also called stitching, plane-fighting, or glitch, is a phenomenon in 3D rendering that occurs when two or more primitives have very similar distances to the camera.

See this for more explanation.

Scope

This standardization cover the Unreal Style Guideline about how to work in Unreal. This standard applies to all person in in team that work using Unreal Engine.

Technical Director and Art Director was the parties whose in charge in these guidelines. While all of the team member should follow these guidelines, they can ask about the guidelines to the directors or can propose some new guidelines here and there.

Unreal Style Guidelines

[S-Production-001] General Naming Convention

[S-Production-001.1] Use English

Using English words for assets in a game project is a common practice for several reasons.

Global Accessibility: English is one of the most widely spoken and understood languages worldwide. By using English for asset names, you make your game more accessible to a global audience. Client from different countries and language backgrounds can better understand and this solve the problem when we need to hand over the project later.
Consistency: English provides a consistent naming convention for assets. It's easier for development teams to communicate and collaborate when everyone uses a common language for asset names. This consistency helps streamline the development process and reduces the chances of misunderstandings.
Cross-Platform Compatibility: Many game development tools and platforms are primarily designed to work with English. Using non-English characters or words in asset names can sometimes lead to compatibility issues, especially when working with third-party tools and engines.
Localization: If you plan to localize your game into multiple languages, starting with English asset names makes the localization process smoother. Translators can easily understand the context and purpose of each asset, which helps maintain the integrity of the game's design and user experience across different languages.
Documentation and Support: When you encounter issues or need to seek help in forums, documentation, or from the gaming community, using English asset names ensures that others can understand your questions and provide assistance effectively.
Asset Management: English asset names are generally easier to manage within asset databases and version control systems. They are less likely to cause encoding or formatting issues that can arise with non-English characters.
Searchability: When working on a large project with many assets, using English names makes it easier to search for specific assets within your project files or directories. It can save time and reduce potential confusion.
Marketplace Compatibility: If you plan to sell your game or assets on online marketplaces or app stores, many of these platforms require English descriptions and asset names as part of their submission guidelines.

[S-Production-001.2] Forbidden Character

In any identifier name of any kind, never use the following unless absolutely forced to:

White space of any kind
Backward slashes \
Symbols i.e. #!@$%
Any Unicode character

Any identifier name should strive to only have the following characters when possible (the RegEx [A-Za-z0-9_]+)

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
1234567890
_ (sparingly)

Localization is outside this rule because localization scope was for displayed contents, not in development assets.

The reasoning for this are:

This will ensure the greatest compatibility of all data across all platforms across all tools.
Prevent downtime due to potentially bad character handling for identifiers in code you don't control.
Prevent unexpected issues in another engineering tools such as automation like CICD.

If one of your game characters is named 'Zoë', its folder name should be Zoe. Unicode characters can be worse than Spaces for engineering tool and some parts of UE4 don't support Unicode characters in paths either.

Related to this, if your project has unexplained issues and your computer's user name has a Unicode character (i.e. your name is Zoë), any project located in your My Documents folder will suffer from this issue. Often simply moving your project to something like D:\Project will fix these mysterious issues.

Using other characters outside a-z, A-Z, and 0-9 such as @, -, _, ,, *, and # can also lead to unexpected and hard to track issues on other platforms, source control, and weaker engineering tools.

[S-Unreal-002] Asset Naming Convention

Consistency is the key to maintainable code and project and naming conventions should be treated as law. A project that conforms to a naming convention is able to have its assets managed, searched, parsed, and maintained with incredible ease.

[S-Unreal-002.1] Asset Naming

Please also remember that all names should be written in English.

[S-Unreal-002.1.1] Use PascalCase For Each Name Segment

PascalCase refers to starting a name with a capital letter and then instead of using spaces, every following word also starts with a capital letter. For example, DesertEagle, RocketPistol, and ASeriesOfWords.

See Cases for Letter.

See Asset Pattern Name.

[S-Unreal-002.1.2] Never Use Spaces

Re-enforcing [S-Unreal-002.1.1], never use spaces. Spaces can cause various engineering tools and batch processes to fail. Ideally, your project's root also contains no spaces and is located somewhere such as D:\Project instead of C:\Users\My Name\My Documents\Unreal Projects.

[S-Unreal-002.1.3] Never Use Unicode Characters And Other Symbols

See Forbidden Character.

[S-Unreal-002.2] Asset Pattern Name

Most things are prefixed with prefixes being generally an acronym of the asset type followed by an underscore.

The naming standard for all asset inside Unreal is separated into 4 segment.

The naming standard pattern is: Prefix_AssetName_Variant_Suffix.

[S-Unreal-002.2.1] AssetName

All assets should have an AssetName that represents a logical grouping of related assets. Any asset that is part of this logical group should follow the standard of Prefix_BaseAssetName_Variant_Suffix.

Keeping the pattern in mind and using common sense is generally enough to warrant good asset names.

AssetName should be determined by a short and easily recognizable name related to the context of this group of assets.
Use PascalCase for example SM_KKKBuildingBasement.
Usually use noun word, except for some asset that by nature was using non noun word.
- Animation, use SkeletonName + _ + AnimationName where the SkeletonName was noun and the AnimationName was verb, for example AM_Pikachu_MeleeAttack_01, AS_Humanoid_Idle_01.
  - Note that AM_Pikachu_MeleeAttack_01 using SKEL_Pikachu as skeleton and AS_Humanoid_Idle_01 using SKEL_Humanoid as skeleton.
- Other blueprint with specific purpose and logic, for example BlueprintTaskNode, ActorComponent that used as handler/updater, etc.

[S-Unreal-002.2.2] Variant

For unique and specific variations of assets, Variant is either a short and easily recognizable name that represents logical grouping of assets that are a subset of an asset's name.

Can be none for example SK_Bulbasaur.
Can be filled with adjective/adverb word and optionally added with increment number for example T_ClumpGrass_Dry_D, T_ClumpGrass_Lush_01_D, T_ClumpGrass_Lush_02_D.
- If Bob had multiple skins these skins should still use Bob in AssetName but include a recognizable Variant. An 'Evil' skin would be referred to as SK_Bob_Evil and a 'Retro' skin would be referred to as SK_Bob_Retro.
Can be filled only with increment number for unique but generic variant asset for example SM_Rock_01, SM_Rock_02, T_SomeExample_01_D.
- Increment number start from 1 and max at 99.
- Should only contain 2 digit, not more, not less.
- If you need more than 2 digit then you probably need to reorganized/recategorize your asset using different AssetName or Variant.
  - SM_Rock_01, SM_Rock_02, …, …, SM_Rock_09, SM_Rock_10, SM_Rock_11, …, …, SM_Rock_99 (max).
Can have multiple variant (chained variant).
- Depending on how your asset variants are made, you can chain together variant names. For example, if you are creating flooring assets for an Arch Viz project you should use the name Flooring with chained variants.
  - Floor_Marble_01, Floor_Maple_01, Floor_Tile_Squares_01.
- LOD
  - SM_ClumpGrass_Lush_01_LOD1

[S-Unreal-002.2.2.1] LOD

We use the same patter as Unreal did, LOD + LOD_Index for example, SM_ClumpGrass_Lush_01_LOD1.

[S-Unreal-002.2.2.2] Texture Pack

It is common practice to pack multiple layers of texture data into one texture. An example of this is packing Emissive, Roughness, Ambient Occlusion together as the Red, Green, and Blue channels of a texture respectively. To determine the suffix, simply stack the given suffix letters from above together, e.g. _ERO.

Packing 4 channels of data into a texture (RGBA) is not recommended except for an Alpha/Opacity mask in the Diffuse/Albedo's alpha channel as a texture with an alpha channel incurs more overhead than one without.

[S-Unreal-002.2.3] Prefix/Suffix

Please notes that:

Most of the commonly used assets were registered here, but not all unreal assets type.
This database will be used as live document and will be updated if necessary
If you can’t find the asset type that you’re searching, find your director!
If you have any complaint, find your director!

[Prefix/Suffix ]([S-Unreal-002] Unreal Asset Naming Convention 6f300d57fb844c1d885b1bb9ac8e5397/Prefix Suffix 536fdf2259c84f63b87255247b9e0241.csv)

[S-Unreal-003] Folder Structure & Naming Convention

Equally important as asset names, the directory structure style of a project should be considered law. Asset naming conventions and content directory structure go hand in hand, and a violation of either causes unneeded chaos.

There are multiple ways to lay out the content of a Unreal project. In this style, we will be using a structure that relies more on filtering and search abilities of the Content Browser for those working with assets to find assets of a specific type instead of another common structure that groups asset types with folders.

The Asset Naming Convention already differentiate asset type using prefix/suffix, hence using folders to contain assets of similar types such as Mesh, Texture, and Material is redundant practice as asset types are already both sorted by prefix as well as able to be filtered in the Content Browser.

Also, using this approach will help us further managing our assets when we need to make Asset Management for Asset Bundle, DLC, or memory management.

Below is example of folder structure.

|-- Content
|   |-- ProjectName
|   |   |-- Media
|   |   |   |-- Ambience
|   |   |   |-- BGM
|   |   |   |-- SFX
|   |   |   |-- Movie
|   |   |-- Art
|   | 	|   |-- General
|   |   |   |   |-- Prop
|   |   |   |-- Industrial
|   |   |   |   |-- Ambient
|   |   |   |   |-- Machinery
|   |   |   |   |-- Pipe
|   |   |   |-- Residential
|   |   |   |   |-- House
|   |   |   |   |-- Prop
|   |   |   |-- Commercial
|   |   |   |   |-- Stadium
|   |   |   |   |-- Store
|   |   |   |-- Nature
|   |   |   |   |-- Ambient
|   |   |   |   |-- Foliage
|   |   |   |   |-- Rock
|   |   |   |   |-- Tree
|   |   |-- Character             <All character related weren't placed inside Art folder>
|   |   |   |-- Humanoid          <No character blueprint here, base character blueprint goes to folder core>
|   |   |   |   |-- Animation     <Animation used by this skeleton>
|   |   |   |   |-- SFX           <SFX that commonly used by all animation>
|   |   |   |   |-- *~~~ Skeleton file ~~~*
|   |   |   |   |-- *~~~ Physic asset file ~~~*
|   |   |   |-- Female
|   |   |   |   |-- Animation     <Animation that commonly used by this common skeleton>
|   |   |   |   |-- SFX           <SFX that commonly used by this common skeleton>
|   |   |   |   |-- 
|   |   |   |-- Bartender         <This character may use BaseMale, BaseFemale, or Common skeleton, but has specific AI, animation, or logic that require separation of context>
|   |   |   |   |-- AI            <AI that commonly exclusively used by this character>
|   |   |   |   |-- Animation     <Animation that exclusively used by this character>
|   |   |   |   |-- SFX           <SFX that exclusively used by this character>
|   |   |   |   |-- *~~~ Character blueprint file ~~~*
|   |   |   |   |-- *~~~ Skeleton mesh file ~~~*
|   |   |   |-- Dog               <Character that use exclusive skeleton or non common sekeleton>
|   |   |   |   |-- AI            <AI that commonly exclusively used by this character>
|   |   |   |   |-- Animations    <Animation that exclusively used by this character>
|   |   |   |   |-- 
|   |   |   |-- BossTentacle      <Character that use exclusive skeleton or non common sekeleton>
|   |   |   |   |-- Animation     <Animation that exclusively used by this character>
|   |   |   |   |-- Dialogue      <Dialogue that exclusively used by this character>
|   |   |   |   |-- SFX           <SFX that exclusively used by this character>
|   |   |   |   |-- ~~~ *Character blueprint file ~~~*
|   |   |   |   |-- ~~~ Skeleton *file ~~~*
|   |   |   |   |-- ~~~ Skeleton mesh 
|   |   |   |   |-- ~~~ Physic asset 
|   |   |-- Core
|   |   |   |-- General           <Global context but used as core system>
|   |   |   |-- AI                <Base AI>
|   |   |   |-- Character         <Base character logic should be placed here>
|   |   |   |-- GameplayFramework <In each sub folder contain GameMode, GameState, PlayerController, PlayerState and all gameplay framework related as they already coupled and binded to each other>
|   |   |   |   |-- MainMenu
|   |   |   |   |-- OpenWorld
|   |   |   |   |-- BattleRoyale
|   |   |   |   |-- MiniGameRace
|   |   |   |-- GameplayAbility
|   |   |   |-- Inventory
|   |   |-- Effect
|   |   |   |-- Electrical
|   |   |   |-- Fire
|   |   |   |-- Weather
|   |   |-- Map
|   |   |   |-- Campaign1
|   |   |   |-- Campaign2
|   |   |-- MaterialLibrary
|   |   |   |-- Debug
|   |   |   |-- Metal
|   |   |   |-- Paint
|   |   |   |-- Utility
|   |   |-- Widget
|   |   |   |-- Common
|   |   |   |   |-- Button
|   |   |   |   |-- PopUp
|   |   |   |   |-- Modal
|   |   |   |-- PlayerHUD
|   |   |   |-- CharacterStat
|   |   |   |-- CharacterSkillTree
|   |   |   |-- Inventory
|   |   |   |-- QuestLog
|   |-- ThirdPartyFolder1
|   |-- ThirdPartyFolder2
|-- Source                           <This example was not editor preview but actual physical folder>
|   |-- ProjectName
|   |   |-- Private
|   |   |-- Public
|   |-- Submodule2
|   |-- Submodule2
|-- Plugins                          <This example was not editor preview but actual physical folder>
|   |-- GameplayFeature
|   |   |-- GameplayFeature1
|   |   |-- GameplayFeature2
|   |-- Plugins1
|   |-- Plugins2
|   |-- Minimap Content
|   |-- Minimap C++ Class
|   |-- Module Content
|   |-- Module C++ Class

[S-Unreal-003.1] Folder Name

Please also remember that all names should be written in English.

[S-Unreal-003.1.1] Always Use Singular Word

Naming folders using singular or plural form in a project structure is a common decision, and there are pros and cons associated with both approaches. The choice often depends on the context and personal or team preferences. Since we need consistency across all project, singular word was chosen with some reason.

Simplicity
- Singular folder names tend to be simpler and more concise. They can make your project structure cleaner and easier to navigate.
Consistency
- If your project's naming convention favors singular names, it can provide a consistent and organized structure throughout your project.
Wordiness
- Plural folder names can be longer and more wordy than singular names, potentially making your project structure slightly more cluttered.

[S-Unreal-003.1.2] Always Use PascalCase

See Cases for Letter.

[S-Unreal-003.1.3] Never Use Spaces

Re-enforcing [S-Unreal-003.1.2], never use spaces. Spaces can cause various engineering tools and batch processes to fail. Ideally, your project's root also contains no spaces and is located somewhere such as D:\Project instead of C:\Users\My Name\My Documents\Unreal Projects.

[S-Unreal-003.1.4] Never Use Unicode Characters And Other Symbols

Folder and file names must contain only English alphanumeric characters and underscores.

If one of your game characters is named 'Zoë', its folder name should be Zoe. Unicode characters can be worse than Spaces for engineering tool and some parts of Unreal don't support Unicode characters in paths either.

See Forbidden Character.

[S-Unreal-003.2] Use A Top Level Folder For Project Specific Assets

All of a project's assets should exist in a folder named after the project. For example, if your project is named 'Generic Shooter', all of it's content should exist in Content/GenericShooter.

The Developers folder is not for assets that your project relies on and therefore is not project specific. See Developer Folders for details about this.

There are multiple reasons for this approach.

[S-Unreal-003.2.1] No Global Assets

Often in code style guides it is written that you should not pollute the global namespace and this follows the same principle. When assets are allowed to exist outside of a project folder, it often becomes much harder to enforce a strict structure layout as assets not in a folder encourages the bad behavior of not having to organize assets.

Every asset should have a purpose, otherwise it does not belong in a project. If an asset is an experimental test and shouldn't be used by the project it should be put in a Developer Folder.

[S-Unreal-003.2.2] Reduce Migration Conflicts

When working on multiple projects it is common for a team to copy assets from one project to another if they have made something useful for both. When this occurs, the easiest way to perform the copy is to use the Content Browser's Migrate functionality as it will copy over not just the selected asset but all of its dependencies.

These dependencies are what can easily get you into trouble. If two project's assets do not have a top level folder and they happen to have similarly named or already previously migrated assets, a new migration can accidentally wipe any changes to the existing assets.

This is also the primary reason why Epic's Marketplace staff enforces the same policy for submitted assets.

After a migration, safe merging of assets can be done using the 'Replace References' tool in the content browser with the added clarity of assets not belonging to a project's top level folder are clearly pending a merge. Once assets are merged and fully migrated, there shouldn't be another top level folder in your Content tree. This method is 100% guaranteed to make any migrations that occur completely safe.

Example 1: Master Material Example

For example, say you created a master material in one project that you would like to use in another project so you migrated that asset over. If this asset is not in a top level folder, it may have a name like Content/MaterialLibrary/M_Master. If the target project doesn't have a master material already, this should work without issue.

As work on one or both projects progress, their respective master materials may change to be tailored for their specific projects due to the course of normal development.

The issue comes when, for example, an artist for one project created a nice generic modular set of static meshes and someone wants to include that set of static meshes in the second project. If the artist who created the assets used material instances based on Content/MaterialLibrary/M_Master as they're instructed to, when a migration is performed there is a great chance of conflict for the previously migrated Content/MaterialLibrary/M_Master asset.

This issue can be hard to predict and hard to account for. The person migrating the static meshes may not be the same person who is familiar with the development of both project's master material, and they may not be even aware that the static meshes in question rely on material instances which then rely on the master material. The Migrate tool requires the entire chain of dependencies to work however, and so it will be forced to grab Content/MaterialLibrary/M_Master when it copies these assets to the other project and it will overwrite the existing asset.

It is at this point where if the master materials for both projects are incompatible in any way, you risk breaking possibly the entire material library for a project as well as any other dependencies that may have already been migrated, simply because assets were not stored in a top level folder. The simple migration of static meshes now becomes a very ugly task.

[S-Unreal-003.2.3] Samples, Templates, and Marketplace Content Are Risk-Free

An extension to [S-Unreal-003.2.2], if a team member decides to add sample content, template files, or assets they bought from the marketplace, it is guaranteed, as long your project's top-level folder is uniquely named, that these new assets will not interfere with your project.

You can not trust marketplace content to fully conform to the top level folder rule. There exists many assets that have the majority of their content in a top level folder but also have possibly modified Epic sample content as well as level files polluting the global Content folder.

When adhering to [S-Unreal-003.2], the worst marketplace conflict you can have is if two marketplace assets both have the same Epic sample content. If all your assets are in a project specific folder, including sample content you may have moved into your folder, your project will never break.

[S-Unreal-003.2.4] DLC, Sub-Projects, and Patches Are Easily Maintained

If your project plans to release DLC or has multiple sub-projects associated with it that may either be migrated out or simply not cooked in a build, assets relating to these projects should have their own separate top level content folder. This make cooking DLC separate from main project content far easier. Sub-projects can also be migrated in and out with minimal effort. If you need to change a material of an asset or add some very specific asset override behavior in a patch, you can easily put these changes in a patch folder and work safely without the chance of breaking the core project.

[S-Unreal-003.3] Use Developers Folder For Local Testing

During a project's development, it is very common for team members to have a sort of 'sandbox' where they can experiment freely without risking the core project. Because this work may be ongoing, these team members may wish to put their assets on a project's source control server. Not all teams require use of Developer folders, but ones that do use them often run into a common problem with assets submitted to source control.

It is very easy for a team member to accidentally use assets that are not ready for use, which will cause issues once those assets are removed. For example, an artist may be iterating on a modular set of static meshes and still working on getting their sizing and grid snapping correct. If a world builder sees these assets in the main project folder, they might use them all over a level not knowing they could be subject to incredible change and/or removal. This causes massive amounts of re-working for everyone on the team to resolve.

If these modular assets were placed in a Developer folder, the world builder should never have had a reason to use them and the whole issue would never happen. The Content Browser has specific View Options that will hide Developer folders (they are hidden by default) making it impossible to accidentally use Developer assets under normal use.

[S-Unreal-003.4] All Map Files Belong In A Folder Called Map

Map files are incredibly special and it is common for every project to have its own map naming system, especially if they work with sub-levels or streaming levels. No matter what system of map organization is in place for the specific project, all levels should belong in /Content/Project/Map.

Being able to tell someone to open a specific map without having to explain where it is is a great time saver and general 'quality of life' improvement. It is common for levels to be within sub-folders of Map, such as Map/Campaign1/ or Map/Arena, but the most important thing here is that they all exist within /Content/Project/Map.

This also simplifies the job of cooking for engineers. Wrangling levels for a build process can be extremely frustrating if they have to dig through arbitrary folders for them. If a team's maps are all in one place, it is much harder to accidentally not cook a map in a build. It also simplifies lighting build scripts as well as QA processes.

[S-Unreal-003.5] Use A `Core` Folder For Critical Blueprints And Other Assets

Use /Content/Project/Core folder for assets that are absolutely fundamental to a project's workings. For example, base GameMode, Character, PlayerController, GameState, PlayerState, and related Blueprints should live here.

This creates a very clear "don't touch these" message for other team members. Non-engineers should have very little reason to enter the Core folder. Following good code structure style, designers should be making their gameplay tweaks in child classes that expose functionality. World builders should be using prefab Blueprints in designated folders instead of potentially abusing base classes.

For example, if your project requires pickups that can be placed in a level, there should exist a base Pickup class in Core/Pickup that defines base behavior for a pickup. Specific pickups such as a Health or Ammo should exist in a folder such as /Content/Project/Placeable/Pickup/. Game designers can define and tweak pickups in this folder however they please, but they should not touch Core/Pickup as they may unintentionally break pickups project-wide.

[S-Unreal-003.6] Forbidden Word For Folders Name

Folders and files must not be vaguely-named such as Assets, NewFolder, etc.

[S-Unreal-003.6.1] Creating a folder named `Assets` / `Asset` is redundant

All assets are assets.

[S-Unreal-003.6.2] Un-renamed `NewFolder` folder

If project has folder named NewFolder in it, then it means the project have unsorted/global context, violate some rules, forgot to rename, or other things that need to be clean up.

[S-Unreal-003.6.3] Creating a folder named `Meshes` / `Mesh`, `Textures` / `Texture`, or `Materials` / `Material` is redundant

All asset names are named with their asset type in mind. These folders offer only redundant information and the use of these folders can easily be replaced with the robust and easy to use filtering system the Content Browser provides.

Want to view only static mesh in Environment/Rock/? Simply turn on the Static Mesh filter. If all assets are named correctly, they will also be sorted in alphabetical order regardless of prefixes. Want to view both static meshes and skeletal meshes? Simply turn on both filters. This eliminates the need to potentially have to Control-Click select two folders in the Content Browser's tree view.

This also extends the full path name of an asset for very little benefit. The SM_ prefix for a static mesh is only two characters, whereas Meshes/ is seven characters.

Not doing this also prevents the inevitability of someone putting a static mesh or a texture in a Material folder.

[S-Unreal-003.7] Very Large Asset Sets Get Their Own Folder Layout

This can be seen as a pseudo-exception to [S-Unreal-003.6].

There are certain asset types that have a huge volume of related files where each asset has a unique purpose. The two most common are Animation and Audio assets. If you find yourself having 15+ of these assets that belong together, they should be together.

For example, animations that are shared across multiple characters should lay in Character/Common/Animation and may have sub-folders such as Locomotion or Cinematic.

This does not apply to assets like textures and materials. It is common for a Rocks folder to have a large amount of textures if there are a large amount of rocks, however these textures are generally only related to a few specific rocks and should be named appropriately. Even if these textures are part of a Material Library.

[S-Unreal-003.8] `MaterialLibrary`

If your project makes use of master materials, layered materials, or any form of reusable materials or textures that do not belong to any subset of assets, these assets should be located in Content/Project/MaterialLibrary.

This way all 'global' materials have a place to live and are easily located.

This also makes it incredibly easy to enforce a 'use material instances only' policy within a project. If all artists and assets should be using material instances, then the only regular material assets that should exist are within this folder. You can easily verify this by searching for base materials in any folder that isn't the MaterialLibrary.

The MaterialLibrary doesn't have to consist of purely materials. Shared utility textures, material functions, and other things of this nature should be stored here as well within folders that designate their intended purpose. For example, generic noise textures should be located in MaterialLibrary/Utility.

Any testing or debug materials should be within MaterialLibrary/Debug. This allows debug materials to be easily stripped from a project before shipping and makes it incredibly apparent if production assets are using them if reference errors are shown.

[S-Unreal-003.9] No Empty Folders

There simply shouldn't be any empty folders. They clutter the content browser.

If you find that the content browser has an empty folder you can't delete, you should perform the following:

Be sure you're using source control.
Immediately run Fix Up Redirectors on your project.
Navigate to the folder on-disk and delete the assets inside.
Close the editor.
Make sure your source control state is in sync (i.e. if using Perforce, run a Reconcile Offline Work on your content directory)
Open the editor. Confirm everything still works as expected. If it doesn't, revert, figure out what went wrong, and try again.
Ensure the folder is now gone.
Submit changes to source control.

[S-Unreal-003.10] Not Too Long Path

Including the name of the top level folder under the Content folder, all asset file paths must be 140 characters or less. Exceed this limit can cause issues in CICD automation caused by too long path.

[S-Unreal-004] Textures Standardization

This section will focus on Texture assets and their internals.

[S-Unreal-004.1] Dimensions Are Powers of 2

All textures, except for UI textures, must have its dimensions in multiples of powers of 2. Textures do not have to be square.

For example, 128x512, 1024x1024, 2048x1024, 1024x2048, 1x512.

[S-Unreal-004.2] Texture Density Should Be Uniform

All textures should be of a size appropriate for their standard use case. Appropriate texture density varies from project to project, but all textures within that project should have a consistent density.

For example, if a project's texture density is 8 pixel per 1 unit, a texture that is meant to be applied to a 100x100 unit cube should be 1024x1024, as that is the closest power of 2 that matches the project's texture density.

[S-Unreal-004.3] Textures Should Be No Bigger than 8192

No texture should have a dimension that exceeds 8192 in size, unless you have a very explicit reason to do so. Often, using a texture this big is simply just a waste of resources.

It’s also recommended that texture don’t exceeds 2048 in size although we were targeting 4K display as we can achieve it using work-around solution like anti-alias and anisotropic bilinear/trilinear.

[S-Unreal-004.4] Textures Should Be Grouped Correctly

Every texture has a Texture Group property used for LOD-ing, and this should be set correctly based on its use. For example, all UI textures should belong in the UI texture group.

This also impacting in how to name the asset, for example UI and ColorLookUpTable group don’t require suffix while the others have.

[S-Unreal-005] Static Meshes Standardization

This section will focus on Static Mesh assets and their internals.

[S-Unreal-005.1] Static Mesh UVs

If Linter is reporting bad UVs and you can't seem to track it down, open the resulting .log file in your project's Saved/Logs folder for exact details as to why it's failing. I am hoping to include these messages in the Lint report in the future.

[S-Unreal-005.1.1] All Meshes Must Have UVs

Pretty simple. All meshes, regardless how they are to be used, should not be missing UVs.

[S-Unreal-005.1.2] All Meshes Must Not Have Overlapping UVs for Lightmaps

Pretty simple. All meshes, regardless how they are to be used, should have valid non-overlapping UVs.

[S-Unreal-005.2] LODs Should Be Set Up Correctly

This is a subjective check on a per-project basis, but as a general rule any mesh that can be seen at varying distances should have proper LODs.

[S-Unreal-005.3] Modular Socket-less Assets Should Snap To The Grid Cleanly

This is a subjective check on a per-asset basis, however any modular socket-less assets should snap together cleanly based on the project's grid settings.

It is up to the project whether to snap based on a power of 2 grid or on a base 10 grid. However if you are authoring modular socket-less assets for the marketplace, Epic's requirement is that they snap cleanly when the grid is set to 10 units or bigger.

[S-Unreal-005.4] All Meshes Must Have Collision

Regardless of whether an asset is going to be used for collision in a level, all meshes should have proper collision defined. This helps the engine with things such as bounds calculations, occlusion, and lighting. Collision should also be well-formed to the asset.

[S-Unreal-005.5] All Meshes Should Be Scaled Correctly

This is a subjective check on a per-project basis, however all assets should be scaled correctly to their project. Level designers or blueprint authors should not have to tweak the scale of meshes to get them to confirm in the editor. Scaling meshes in the engine should be treated as a scale override, not a scale correction.

[S-Unreal-006] Skeletal Meshes Standardization

// TODO: write rules here

[S-Unreal-007] Audio Standardization

This section will focus on Media assets such as audio and video, and their internals.

[S-Unreal-007.1] Audio Sample Rate Should Between 22050Hz - 44100Hz

Audio sample rates outside the typical range of 22,050 Hz to 44,100 Hz can lead to various issues depending on the context in which they are used. The sample rate of an audio file determines the number of samples taken per second to represent the audio waveform. Here are some potential issues associated with using audio sample rates outside the standard range:

Quality Loss: Lower sample rates (e.g., 8,000 Hz) can result in a significant loss of audio quality, particularly for music and high-frequency sounds. The audio may sound distorted, lack clarity, and lose fidelity.
Aliasing: Using a sample rate lower than the Nyquist rate (half of the desired audio frequency range) can lead to aliasing. Aliasing is an undesirable effect where high-frequency components of the audio signal are incorrectly interpreted as lower-frequency components, resulting in distortion.
Incompatibility: Some audio equipment and software may not support sample rates outside the typical range. This can lead to compatibility issues when playing or processing the audio.
Large File Sizes: Higher sample rates result in larger audio files. If you use a very high sample rate unnecessarily, it can lead to large file sizes, which may not be practical for storage or transmission.
Processing Overhead: High sample rates require more computational resources for processing, which can be a concern in resource-constrained environments such as mobile devices or real-time audio processing applications.
Interpolation/Resampling: If you need to convert audio with a non-standard sample rate to a more common rate (e.g., 44,100 Hz), you may encounter issues related to interpolation and resampling, which can introduce artifacts and affect audio quality.
Synchronization: In multimedia applications where audio needs to be synchronized with video or other events, using a non-standard sample rate can complicate synchronization and lead to audio/video desynchronization issues.
Standards and Compatibility: Many audio and video standards, such as those used in broadcasting and streaming, are based on common sample rates like 44,100 Hz or 48,000 Hz. Using non-standard sample rates may not conform to these standards, affecting compatibility and quality in those contexts.

In most cases, it is recommended to use standard sample rates like 22,050 Hz, 44,100 Hz, or 48,000 Hz for audio recording, production, and distribution, as they are widely supported and provide good audio quality. If there are specific reasons to use a non-standard sample rate, it's essential to be aware of the potential issues and ensure that the chosen sample rate aligns with the requirements of your project and the capabilities of the equipment and software you are using.

[S-Unreal-008] Niagara Particle System Standardization

~~This section will focus on Niagara particle system assets and their internals.~~

[S-Unreal-008.1] Emitter Naming

~~All emitters in a Particle System should be named something descriptive and not left to their default name "Particle Emitter".~~

[S-Unreal-008.1.1] No Spaces, Ever

~~As mentioned in~~ ~~[S-Production-001.2] Forbidden Character~~, spaces and all white space characters are forbidden in identifiers. This is especially true for Niagara systems as it makes working with things significantly harder if not impossible when working with HLSL or other means of scripting within Niagara and trying to reference an identifier.{{@2352#bkmrk-include-content}}

[S-Unreal-009] Maps Standardization

~~This section will focus on Level assets and their internals.~~

[S-Unreal-009.1] No Errors Or Warnings

~~All levels should load with zero errors or warnings. If a level loads with any errors or warnings, they should be fixed immediately to prevent cascading issues.~~

~~You can run a map check on an open level in the editor by using the console command "map check".~~

~~Please note: Linter is even more strict on this than the editor is currently, and will catch load errors that the editor will resolve on its own.~~

[S-Unreal-009.2] Static/Stationary Lighting Should Be Built

It is normal during development for levels to occasionally not have lighting built. When doing a test/internal/shipping build or any build that is to be distributed however, lighting should always be built.

[S-Unreal-009.3] No Player Visible Z Fighting

~~Levels should not have any~~ ~~z-fighting~~ ~~in all areas visible to the player.~~

[S-Unreal-009.4] Maps for Preview / Prototype / Vertical Slice

~~If a project is to be sold on the Unreal Marketplace, it must follow these rules.~~

[S-Unreal-009.4.1] Overview Level (Asset)

~~If your project contains assets that should be visualized or demoed, you must have a map within your project that contains the name "Overview".~~

This overview map, if it is visualizing assets, should be set up according to [Epic's guidelines](http://help.epicgames.com/customer/en/portal/articles/2592186-marketplace-submission-guidelines-preparing-your-assets#Required Levels and Maps).

~~For example,~~ InteractionComponent_Overview.

[S-Unreal-009.4.2] Demo Level (Mechanic)

If your project contains assets that should be demoed or come with some sort of tutorial, you must have a map within your project that contains the name "Demo". This level should also contain documentation within it in some form that illustrates how to use your project. See Epic's Content Examples project for good examples on how to do this.

~~If your project is a gameplay mechanic or other form of system as opposed to an art pack, this can be the same as your "Overview" map.~~

~~For example,~~ InteractionComponent_Overview_Demo, ExplosionKit_Demo.{{@2353#bkmrk-include-content}}

[S-Unreal-010] Blueprints Standardization

[S-Unreal-011] C++ Standardization

Reference

[S-Unreal] Unreal Style Guidelines

[G-Production-001] Development Principles

[S-Unreal-001] Unreal Standardization Terminology

[S-Production-001] General Naming Convention

[S-Unreal-002] Unreal Asset Naming Convention

[S-Unreal-003] Unreal Folder Structure & Naming Convention

[S-Unreal-004] Textures Standardization

[S-Unreal-005] Static Meshes Standardization

[S-Unreal-006] Skeletal Meshes Standardization

[S-Unreal-007] Media Standardization

[S-Unreal-008] Niagara Particle System Standardization

[S-Unreal-009] Maps Standardization

[S-Unreal-010] Blueprint Standardization

[S-Unreal-011] C++ Standardization

Linter Index

[Index]([S-Unreal] Unreal Style Guidelines 80893b3a9d024025a0a78d4259fcd4f3/Index a9ec1c678e9e4156954453cf90020e1b.csv)

[S-Unreal] Unreal Style Guidelines

Overview

[Production-001.1] If your project already has a style guide, you should follow it

[Production-001.2] All structure, assets, and code in any project should look like a single person created it, no matter how many people contributed

[Production-001.3] Friends do not let friends have bad style

[Production-001.4] A team without a style guide is no team of mine

[Production-001.5] Don't Break The Law

[Unreal-001.1] Cases for letter

[Unreal-001.2] Incremental Number

[Unreal-001.3] Z-Fighting

Scope

Unreal Style Guidelines

[S-Production-001.1] Use English

[S-Production-001.2] Forbidden Character

[S-Unreal-002.1] Asset Naming

[S-Unreal-002.1.1] Use PascalCase For Each Name Segment

[S-Unreal-002.1.2] Never Use Spaces

[S-Unreal-002.1.3] Never Use Unicode Characters And Other Symbols

[S-Unreal-002.2] Asset Pattern Name

[S-Unreal-002.2.1] AssetName

[S-Unreal-002.2.2] Variant

[S-Unreal-002.2.2.1] LOD

[S-Unreal-002.2.2.2] Texture Pack

[S-Unreal-002.2.3] Prefix/Suffix

[S-Unreal-003.1] Folder Name

[S-Unreal-003.1.1] Always Use Singular Word

[S-Unreal-003.1.2] Always Use PascalCase

[S-Unreal-003.1.3] Never Use Spaces

[S-Unreal-003.1.4] Never Use Unicode Characters And Other Symbols

[S-Unreal-003.2] Use A Top Level Folder For Project Specific Assets

[S-Unreal-003.2.1] No Global Assets

[S-Unreal-003.2.2] Reduce Migration Conflicts

[S-Unreal-003.2.3] Samples, Templates, and Marketplace Content Are Risk-Free

[S-Unreal-003.2.4] DLC, Sub-Projects, and Patches Are Easily Maintained

[S-Unreal-003.3] Use Developers Folder For Local Testing

[S-Unreal-003.4] All Map Files Belong In A Folder Called Map

[S-Unreal-003.5] Use A Core Folder For Critical Blueprints And Other Assets

[S-Unreal-003.6] Forbidden Word For Folders Name

[S-Unreal-003.6.1] Creating a folder named Assets / Asset is redundant

[S-Unreal-003.6.2] Un-renamed NewFolder folder

[S-Unreal-003.6.3] Creating a folder named Meshes / Mesh, Textures / Texture, or Materials / Material is redundant

[S-Unreal-003.7] Very Large Asset Sets Get Their Own Folder Layout

[S-Unreal-003.8] MaterialLibrary

[S-Unreal-003.9] No Empty Folders

[S-Unreal-003.10] Not Too Long Path

[S-Unreal-004.1] Dimensions Are Powers of 2

[S-Unreal-004.2] Texture Density Should Be Uniform

[S-Unreal-004.3] Textures Should Be No Bigger than 8192

[S-Unreal-004.4] Textures Should Be Grouped Correctly

[S-Unreal-005.1] Static Mesh UVs

[S-Unreal-005.1.1] All Meshes Must Have UVs

[S-Unreal-005.1.2] All Meshes Must Not Have Overlapping UVs for Lightmaps

[S-Unreal-005.2] LODs Should Be Set Up Correctly

[S-Unreal-005.3] Modular Socket-less Assets Should Snap To The Grid Cleanly

[S-Unreal-005.4] All Meshes Must Have Collision

[S-Unreal-005.5] All Meshes Should Be Scaled Correctly

[S-Unreal-007.1] Audio Sample Rate Should Between 22050Hz - 44100Hz

[S-Unreal-008.1] Emitter Naming

[S-Unreal-008.1.1] No Spaces, Ever

[S-Unreal-009.1] No Errors Or Warnings

[S-Unreal-009.2] Static/Stationary Lighting Should Be Built

[S-Unreal-009.3] No Player Visible Z Fighting

[S-Unreal-009.4] Maps for Preview / Prototype / Vertical Slice

[S-Unreal-009.4.1] Overview Level (Asset)

[S-Unreal-009.4.2] Demo Level (Mechanic)

Reference

Related Pages

Linter Index

[S-Unreal-003.5] Use A `Core` Folder For Critical Blueprints And Other Assets

[S-Unreal-003.6.1] Creating a folder named `Assets` / `Asset` is redundant

[S-Unreal-003.6.2] Un-renamed `NewFolder` folder

[S-Unreal-003.6.3] Creating a folder named `Meshes` / `Mesh`, `Textures` / `Texture`, or `Materials` / `Material` is redundant

[S-Unreal-003.8] `MaterialLibrary`