A Practical Studio Standard for Clean, Scalable Projects

A good naming convention is not glamorous, but it matters.

In Unreal Engine projects, poor naming creates friction fast. Assets become hard to find, folders turn into junk drawers, and the project starts to feel bigger and messier than it really is. A clear naming standard fixes that. It helps you move faster, reduces confusion, and makes the project easier to maintain as it grows.

If you are working on a large team, the naming conventions and project structure have likely already been defined and established.

However, if you are a solo indie developer, it is worth defining your own style early in the project. A clear standard can help keep the project organized, consistent, and easier to maintain as it grows.

What follows is my own practical naming convention for Unreal Engine. It is not meant to be bloated or academic. It is meant to be used.

At the end of the article, I also included useful resources.

Why a naming convention matters

A naming convention does a few simple but important things:

• makes assets easier to find
• reduces duplicate or ambiguous names
• keeps folders readable
• helps separate your own assets from template or third-party content
• makes Blueprints and code easier to understand
• keeps the project from turning into a mess over time

The goal is not perfection. The goal is consistency.

Core rules

These rules should apply across the entire project:

• Use PascalCase
• Do not use spaces
• Do not use hyphens
• Do not start names with numbers
• Keep names short but descriptive
• Use asset-type prefixes consistently
• Avoid vague names like NewBlueprint, Widget1, TestAsset, or Final_Final

A simple general pattern is:

Prefix_Name_Descriptor_Variant

Examples:

• BP_PDPlayerCharacter
• WBP_MainMenu
• DA_PlayerDefaults
• L_Dev_Gym

Not every asset needs every part of that formula. Most names should stay short.

Project name

The Unreal project name should be clean and simple.

Use this format:

GameName

Good examples:

• ProjectDrift
• NeonOutpost
• SkywardRun

Avoid names like:

• My Awesome Game
• UE57PrototypeFinal
• Cyberpunk-Project

The project name should not try to do too much. Keep it clean. Save the detail for folders and asset names.

Root content folder

All game content should live inside one root folder under Content.

Example:

Content/ProjectDrift

This keeps your game content separate from starter content, marketplace assets, and plugins. It also makes the project much easier to manage later.

Do not scatter important project assets directly under Content.

Folder structure

A feature-based folder structure usually works better than one giant folder for each technical asset type.

A solid starting structure looks like this:

Content/
  ProjectDrift/
    Core/
    Characters/
    Combat/
    Interaction/
    UI/
    Input/
    Data/
    Levels/
    World/
    Audio/
    Dev/

This is simple, readable, and scalable.

The key point is to separate real game content from temporary development content. Shipping assets should not live in the same chaos pile as experimental test assets.

Project token

For major project-specific assets and classes, it helps to use a short project token.

For a sample project called ProjectDrift, a good token would be:

PD

Examples:

• BP_PDPlayerCharacter
• BP_PDGameMode
• ABP_PDPlayer

This is useful because it separates your own core assets from engine templates, sample content, and marketplace packs.

Level naming

Use L_ for all maps.

Examples:

• L_MainMenu
• L_Prologue
• L_Hub
• L_M01_Docks
• L_Dev_Gym
• L_Test_Combat

This keeps level naming simple and consistent.

A good rule is to make a clear distinction between:

• shipping maps
• development maps
• test maps

What you want to avoid is the usual junk:

• Level1
• Map_New
• TopDownExampleMap_Final

That kind of naming is how projects age badly.

Blueprint naming

Use clear prefixes for Blueprint asset types.

Recommended prefixes:

• BP_ = Blueprint class
• BPI_ = Blueprint Interface
• BPC_ = Blueprint Component
• ABP_ = Animation Blueprint
• BT_ = Behavior Tree
• BB_ = Blackboard

Examples:

• BP_PDPlayerCharacter
• BP_PDGameMode
• BPI_Interactable
• BPC_Health
• ABP_PDPlayer

This keeps the asset type obvious at a glance and makes searching far easier.

Widget naming

Use WBP_ for all Widget Blueprints.

Examples:

• WBP_MainMenu
• WBP_HUD
• WBP_InventoryPanel
• WBP_DialogueChoiceRow

Name widgets by screen or function. Do not invent creative naming schemes here. UI naming should be boring and obvious.

That is a good thing.

Input naming

For Enhanced Input, use a simple two-prefix system:

• IA_ = Input Action
• IMC_ = Input Mapping Context

Examples:

• IA_Move
• IA_Look
• IA_Jump
• IA_Interact
• IMC_Default
• IMC_UI

Name input actions by what the player is trying to do, not by the hardware being used. IA_Move is good. IA_WASDMove is not.

Data asset naming

Data assets should also follow a clean prefix structure.

Recommended prefixes:

• DA_ = Data Asset
• PDA_ = Primary Data Asset
• DT_ = Data Table
• ST_ = String Table
• CRV_ = Curve

Examples:

• DA_PlayerDefaults
• PDA_Weapon_Pistol
• DT_Weapons
• ST_UI
• CRV_AimAssist

This gives you a practical way to separate configuration-style assets, authored primary content, and table-driven data.

Common asset prefixes

Here is a short reference list for common Unreal asset types:

You do not need to make this more complicated than it is.

Modules

If you are using C++, keep module names clean and aligned with folder names.

Recommended structure for the sample project:

• ProjectDrift
• ProjectDriftEditor

Example:

Source/
  ProjectDrift/
  ProjectDriftEditor/

Do not split into many modules too early. A small project does not need a grand architecture diagram pretending to be a large studio pipeline.

Keep it simple until complexity forces change.

Plugins

Plugins should also have clean, readable names.

Examples:

• PDCombat
• PDDialogue
• PDTools

For internal plugins, using the project token helps avoid collisions and makes ownership obvious.

As with the rest of the naming system, the point is clarity.

Example naming stack

Here is what a consistent project stack might look like for ProjectDrift.

Project

• ProjectDrift

Root content folder

• Content/ProjectDrift

Modules

• ProjectDrift
• ProjectDriftEditor

Plugins

• PDCombat
• PDDialogue
• PDTools

Maps

• L_MainMenu
• L_Dev_Gym
• L_Test_Combat

Core Blueprints

• BP_PDGameMode
• BP_PDPlayerController
• BP_PDPlayerCharacter

UI

• WBP_MainMenu
• WBP_HUD

Input

• IA_Move
• IA_Look
• IMC_Default

Data

• DA_PlayerDefaults
• PDA_Weapon_Pistol
• DT_Weapons

This is enough structure to keep the project sane without becoming bureaucratic.

Final thoughts

A naming convention is not exciting, but it is one of those things that quietly affects everything.

When names are clear, the whole project feels easier to work in. When names are sloppy, every task becomes a little more annoying than it should be. That frustration adds up.

The best naming convention is not the most elaborate one. It is the one your studio will actually follow.

For Unreal Engine 5.7, that usually means one clean project name, one root content folder, consistent prefixes, and a structure that separates real game content from temporary junk. Keep it clear. Keep it consistent. Do not overcomplicate it.

Resources

Recommended Asset Naming Conventions in Unreal Engine projects | Unreal Engine 5.7 Documentation | Epic Developer Community

A recommended naming convention to help organize your Assets for large Unreal Engine projects.

Epic Games Developer

GitHub - Allar/ue5-style-guide: An attempt to make Unreal Engine 4 projects more consistent

An attempt to make Unreal Engine 4 projects more consistent - Allar/ue5-style-guide

GitHubAllar