Game Asset Naming Conventions for Unity and Unreal That Stay Useful as Projects Grow

Naming conventions are boring until the project becomes large enough that bad names start costing money.

A folder with Cube.001, newdoor_FINAL2, material3, texture copy and weapon_last_REAL can survive a prototype. It becomes expensive once several people need to search, replace, automate, export or review those files.

The purpose of a naming convention is not to make filenames look professional. It is to make assets predictable.

If you want to generate examples while reading, use the free Game Asset Naming Convention Generator.

A good name answers useful questions

A filename should help a developer understand the asset without opening it.

For most pipelines, the useful questions are:

• What kind of asset is this?
• What object does it represent?
• Which variant is it?
• Is it a specific LOD or map type?
• Is it related to a known set or system?

That leads to a simple structure:

Type + Base Name + Variant + Technical Suffix

For example:

SM_GothicDoor_A_LOD0

MAT_GothicDoor

T_GothicDoor_BaseColor

The exact prefixes matter less than consistency.

Use short type prefixes

Type prefixes help search and filtering.

A simple cross-engine set might be:

Unreal teams often use conventions such as SM_, M_, T_, BP_ and similar engine-oriented prefixes.

Unity does not require those names, but a predictable prefix still helps large projects because Unity's Project search becomes more useful.

Do not use ten different prefixes for the same thing.

Name the object by what it is, not how you feel about it

Avoid vague names such as:

• CoolSword
• BetterDoor
• NewCrate
• FinalChair
• BigThing

Use descriptive nouns:

• GothicLongsword
• ArcaneWorkshopDoor
• StorageCrateLarge
• BlacksmithChair

The name should survive after the person who created it forgets why it was called “better.”

Variants should be explicit

If multiple models share one role, use a stable variant system.

Examples:

SM_StorageCrate_A

SM_StorageCrate_B

SM_StorageCrate_C

or descriptive variants:

SM_StorageCrate_Open

SM_StorageCrate_Closed

SM_StorageCrate_Broken

Letters are compact and work well when variants are visually similar. Descriptive suffixes work better when the difference affects gameplay or usage.

Do not mix both systems randomly.

Avoid version numbers in runtime asset names

Version history belongs in source control or production tracking, not usually in the final asset name.

Names such as:

Sword_v7_FINAL_FINAL2

create several problems:

• nobody knows which version is actually used;
• automation becomes harder;
• references may point to obsolete assets;
• old versions remain in the project because deleting them feels risky.

Keep working versions outside the runtime asset folder when possible.

The asset inside the game should normally have one stable identity.

Texture names need map suffixes

Texture names become much easier to audit when the map type is always visible.

For example:

T_GothicDoor_BaseColor

T_GothicDoor_Normal

T_GothicDoor_ORM

T_GothicDoor_Emissive

If your pipeline packs multiple channels into one texture, make the packing convention clear.

For example, ORM may mean occlusion, roughness and metallic packed into RGB channels. If a team uses a different order, document it.

A name cannot fix an undocumented channel convention.

LODs should be machine-readable

Use predictable suffixes:

SM_GothicTower_LOD0

SM_GothicTower_LOD1

SM_GothicTower_LOD2

Avoid:

Tower_Low

Tower_Lower

Tower_ReallyLow

Numeric LOD names are easier for people, scripts and engine importers to understand.

Keep spaces and unusual characters out of production names

Most modern tools can handle spaces, but pipelines become more robust when names are simple.

A conservative rule is:

• letters;
• numbers;
• underscores;
• one consistent capitalization style.

Avoid punctuation that may behave differently between file systems, exporters or build scripts.

For example:

SM_ArcaneForge_A

is safer than:

Arcane Forge (NEW!) #A

Do not encode everything into the filename

A filename should be useful, not a database.

Bad example:

SM_Medieval_Gothic_Blacksmith_Forge_Wood_Iron_BlueMagic_GameReady_4K_LOD0_A

That becomes hard to scan and easy to break.

Keep only information that helps identify or process the asset.

Tags, metadata, documentation and folder structure can hold the rest.

Folder structure and naming should work together

A strong naming system does not need to repeat the entire folder path.

If an asset already lives in:

Assets/Environment/Blacksmith/Props/

then the filename may only need:

SM_QuenchingTrough_A

instead of:

SM_Environment_Blacksmith_Props_QuenchingTrough_A

Redundancy is useful only when assets frequently move between folders or are exported independently.

Use one naming rule across outsourced work

Naming problems become especially expensive when external artists deliver files differently.

A contractor brief should define:

• prefix rules;
• capitalization;
• variant format;
• texture suffixes;
• LOD format;
• material naming;
• prefab / blueprint naming;
• source-file naming if required.

This prevents cleanup work after every delivery.

The free 3D Asset Brief Generator can help capture those technical requirements before work starts.

Keep source files and runtime files distinct

A Blender source file may contain multiple objects and production helpers that never enter the game.

For example:

SRC_ArcaneForge.blend

may export:

SM_ArcaneForge_A.fbx

SM_ArcaneForge_Grate.fbx

SM_ArcaneForge_Door.fbx

The source file is a production container. The runtime assets are game objects.

Treating those as different layers reduces confusion.

Naming conventions should support search

A convention is successful when you can answer questions quickly.

Examples:

• Search SM_GothicDoor to find all door meshes.
• Search T_GothicDoor to find every texture for the door.
• Search _LOD1 to inspect all level-of-detail assets.
• Search _Normal to audit normal maps.
• Search MAT_Blacksmith to review materials in one visual family.

If your naming system cannot help with these tasks, it may be too decorative and not functional enough.

Naming helps marketplace production too

Asset sellers have another reason to stay organized: one product may contain source files, FBX exports, textures, preview files and documentation.

A clean package might look like:

Models/SM_ArcaneForge_A.fbx

Materials/MAT_ArcaneForge.mat

Textures/T_ArcaneForge_BaseColor.png

Textures/T_ArcaneForge_Normal.png

Documentation/README.txt

That structure reduces support questions and lowers the chance of uploading the wrong file.

If you publish game assets commercially, the Marketplace Listing Audit checks the customer-facing side of the product: title, description, tags, buyer clarity and bundle opportunities.

Example convention for a small Unity project

A practical small-team convention could be:

• SM_ — static meshes;
• PF_ — prefabs;
• MAT_ — materials;
• T_ — textures;
• ANIM_ — animation clips;
• AUD_ — audio assets.

Example set:

SM_BlacksmithForge_A

PF_BlacksmithForge_A

MAT_BlacksmithForge

T_BlacksmithForge_BaseColor

T_BlacksmithForge_Normal

T_BlacksmithForge_ORM

The important part is not that these prefixes are universally correct. The important part is that every new asset follows the same rule.

Example convention for Unreal

A simple Unreal-oriented set might use:

• SM_ — static mesh;
• SK_ — skeletal mesh;
• M_ — material;
• MI_ — material instance;
• T_ — texture;
• BP_ — blueprint;
• A_ — animation asset.

Again, adapt this to the actual project standards rather than blindly copying a list from another studio.

Write the rules down

A naming convention that exists only in one person's memory does not exist.

Keep a short document with examples.

It should answer:

1. What prefixes are used?
2. How are words capitalized?
3. How are variants represented?
4. How are texture maps named?
5. How are LODs named?
6. Which characters are allowed?
7. Where do working versions live?

One page is enough for most small teams.

Automate the boring part

Once the convention is stable, tools can generate names instead of relying on memory.

The Game Asset Naming Convention Generator creates quick examples for meshes, prefabs, materials, textures and variants across general, Unity and Unreal-style naming patterns.

The generator is intentionally simple. Its purpose is to prevent inconsistent ad-hoc names, not to impose one universal studio standard.

The best naming system is the one people actually follow

Do not build a 40-page naming bible for a three-person team.

A good small-team convention should be:

• easy to remember;
• easy to search;
• easy to type;
• useful to automation;
• clear to external contractors;
• stable for the life of the project.

If people constantly break the convention because it is too complicated, simplify it.

The goal is not perfect filenames. The goal is less wasted time.

Useful next steps: try the Game Asset Naming Convention Generator, create a technical handoff with the 3D Asset Brief Generator, or run the Unity Asset Preflight Auditor before release or handoff.